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Abstract.  Auditing  system  logs  is  an  important  means  of  ensuring  systems’  security  in  situations 
where  run-time  security  mechanisms  are  not  sufficient  to  completely  prevent  potentially  malicious  ac¬ 
tivities.  A  fundamental  requirement  for  reliable  auditing  is  the  integrity  of  the  log  entries.  This  paper 
presents  an  infrastructure  for  secure  logging  that  is  capable  of  detecting  the  tampering  of  logs  by  pow¬ 
erful  adversaries  residing  on  the  device  where  logs  are  generated.  We  rely  on  novel  features  of  trusted 
hardware  (TPM)  to  ensure  the  continuity  of  the  logging  infrastructure  across  power  cycles  without 
help  from  a  remote  server.  Our  infrastructure  also  addresses  practical  concerns  including  how  to  han¬ 
dle  high-frequency  log  updates,  how  to  conserve  disk  space  for  storing  logs,  and  how  to  efficiently 
verify  an  arbitrary  subset  of  the  log.  Importantly,  we  formally  state  the  tamper-proofness  guarantee 
of  our  infrastructure  and  verify  that  our  basic  secure  logging  protocol  provides  the  desired  guaran¬ 
tee.  To  demonstrate  that  our  infrastructure  is  practical,  we  implement  a  prototype  and  evaluate  its 
performance. 


1  Introduction 

Run-time  security  mechanisms  often  are  not  sufficient  to  completely  prevent  malicious  activities.  Under  such 
circumstances,  auditing  system  logs  is  an  important  means  of  ensuring  systems’  security.  A  fundamental 
requirement  for  reliable  auditing  is  the  integrity  of  log  entries.  Adversaries  may  benefit  significantly  from 
tampering  with  log  entries;  for  instance,  malware  may  erase  log  entries  recording  its  installation  or  presence 
in  order  to  avoid  detection  and  subsequent  removal  by  anti-malware  software.  Or,  an  authorized  insider  may 
view  private  customer  data  in  violation  of  company  policy,  then  remove  evidence  of  his  malfeasance  from 
the  access  log  so  that  audits  do  not  detect  it. 

There  has  been  much  work  on  developing  tamper-proof  logging  protocols  [1-5] .  These  protocols  aim  to 
attest  to  the  integrity  of  logs  as  well  as  detect  tampering  of  logs  by  the  adversary.  Some  provide  tamper¬ 
proofness  by  online  commitments  of  current  log  state  [3];  others  store  logs  in  secure  memory  [4].  Some  use 
the  TPM  monotonic  counter  to  attest  to  the  integrity  of  every  log  entry  [2];  others  use  hash  chain  based 
approach  [1].  However,  these  schemes  do  not  meet  the  stringent  requirements  for  tamper-proof  logging  in 
today’s  computing  environment.  Next  we  explain  these  requirements  through  a  realistic  scenario. 

Consider  a  scenario,  where  the  organization,  by  means  of  auditing,  aims  to  enforce  policies  such  as, 
“confidential  documents  stored  on  company-owned  devices  must  never  be  transferred  to  an  external  USB 
storage  device.”  The  organization  mandates  that  all  employee  devices,  such  as  laptops  and  iPads,  run  an 
application  that  monitors  actions  relevant  to  the  policy.  The  logging  infrastructure  needs  to  protect  audit 
logs  on  these  devices.  Since  many  of  these  devices  are  often  offline,  the  first  requirement  is  that  the  integrity 
of  the  audit  log  is  not  dependent  on  continuous  connectivity  to  a  central  server.  Adding  a  log  entry  should  not 
require  connection  to  a  server.  Further,  the  device  could  power  off,  then  restart  with  no  connectivity  to  the 
network  (e.g.,  the  device  is  turned  on  during  flight).  Consequently,  a  second  requirement  is  that  the  logging 
infrastructure  needs  to  preserve  its  continuity  across  power  cycles  without  contacting  a  remote  server. 

It  is  difficult  to  segregate  security-relevant  events  from  security-irrelevant  ones.  The  logging  process  is 
often  required  to  capture  a  large  variety  of  events  from  many  processes  (e.g.,  OS,  browser).  Therefore,  a  third 
requirement  is  that  logging  should  be  fast  enough  to  support  high-frequency  log  updates.  Finally,  devices 
have  only  limited  disk  space.  The  last  requirement  is  that  the  logging  infrastructure  should  work  with  limited 
disk  space  for  storing  logs. 

All  aforementioned  schemes  lack  at  least  one  of  the  features  required  for  our  application:  they  lack 
support  for  either  offline  tamper-proofness  [3,5];  or  large  logs  on  the  order  of  gigabytes  [4];  or  continuous 


logging  across  power  cycles  [1,6];  or  high  frequency  logging  [1,2,4,  7, 8].  In  this  paper,  we  present  a  logging 
infrastructure  that  satisfies  all  of  these  requirements.  The  security  guarantee  of  our  logging  infrastructure  is 
based  on  a  forward  integrity  adversary  model  [9] ,  where  the  adversary  can  obtain  administrative  privileges 
and  take  complete  control  of  the  system.  Our  infrastructure  ensures  that  the  adversary’s  actions  leading  up 
to  the  action  of  compromising  the  machine  will  be  logged  and  cannot  be  tampered  with,  and  therefore,  can 
be  detected. 

Our  logging  infrastructure  is  mainly  composed  of  two  entities:  a  logger  and  a  verifier.  Initially,  the  logger 
and  the  verifier  share  a  secret  key.  As  the  system  executes,  the  logger  generates  a  new  key  for  every  new 
log  entry,  and  uses  the  key  to  compute  the  HMAC  of  the  log  entry  in  order  to  attest  to  the  log  entry’s 
integrity.  The  key  sequence  is  generated  as  a  hash  chain]  the  initial  key  is  known  only  to  the  logger  and 
verifier,  similarly  to  the  scheme  by  Schneier  et  al.  [1].  At  any  given  time  point,  only  the  key  on  top  of  the 
chain  is  used;  older  keys  are  deleted  from  memory.  When  an  adversary  takes  control  of  the  system,  it  cannot 
find  old  keys  in  memory.  The  hash-chained  key  sequence  ensures  that,  without  knowledge  of  the  initial  key, 
old  keys  cannot  be  derived  from  the  key  currently  stored  in  memory.  Thus,  the  adversary  cannot  produce 
valid  HMACs  for  earlier  log  entries. 

To  allow  high-frequency  logging,  our  hash  chain  is  constructed  in  software,  instead  of  the  PCR  registers  in 
the  TPM.  This  greatly  reduces  the  time  required  to  append  a  log  entry.  Furthermore,  we  develop  mechanisms 
that  allow  truncation  of  the  log  after  verification  and  allow  a  verifier  to  efficiently  verify  any  subset  of  the 
log.  As  a  result,  our  infrastructure  works  with  limited  disk  space. 

One  of  the  main  novelties  of  our  infrastructure,  compared  to  Schneier  et  al.  [1],  lies  in  leveraging  TPM 
2.0  features  to  maintain  the  continuity  and  secrecy  of  the  key  chain  across  a  power  cycle.  Specifically,  we  use 
the  ability  to  seal  data  to  values  of  a  TPM  monotonic  counter,  which  TPM1.2  does  not  allow.  At  system 
shutdown,  we  create  a  blob  by  sealing  the  last  key  before  powering  off  to  the  valne  of  a  TPM  monotonic 
counter.  Upon  device  restarts,  the  logger  can  recover  the  key  by  unsealing  the  blob.  Our  creation  of  use  once 
and  discard  blobs  for  logging  is  a  novel  use  of  TPM  2.0’s  sealing  to  a  monotonic  counter  feature. 

In  addition  to  the  design  and  prototype  implementation  of  our  infrastructure,  we  formally  verify  the 
tamper-proofness  property  of  the  basic  protocol,  which  we  consider  as  one  of  our  key  contributions.  We 
believe  this  is  the  first  formal  proof  of  security  for  a  logging  protocol.  The  analysis  brings  out  a  number  of 
assumptions  that  the  system  must  satisfy  to  ensure  tamper-proofness. 

The  rest  of  the  paper  is  organized  as  follows.  We  define  the  adversary  model  and  review  TPM  2.0  features 
in  Section  2.  Our  logging  protocols  are  presented  in  Sections  3  and  4.  Section  5  details  the  verification  steps  of 
the  basic  protocol.  We  describe  our  prototype  implementation  and  evaluation  results  in  Section  6.  Section  7 
discusses  related  work. 

2  Overview 

Review  of  TPM2.0  We  list  features  of  TPM2.0  that  are  key  to  ensuring  tamperproofness  property  of  our 
protocols  [10]. 

NV  memory  TPM  2.0  allows  for  a  larger  non-volatile  memory  than  TPM  1.2.  Its  expected  size  is  more 
than  a  megabyte. 

Monotonic  NV  counter  Any  memory  slot  in  NV  memory  can  be  tagged  as  a  monotonic  counter,  which 
can  only  be  incremented;  it  starts  with  a  value  greater  than  the  maximum  of  all  counters  that  ever 
existed  in  this  TPM. 

Enhanced  authorizations  TPM  2.0  provides  enhanced  authorization  by  defining  authorization  policies, 
which  can  be  the  conjunctions  and  disjunctions  of  basic  policies.  Basic  policies  include  checking  whether 
an  NV  memory  location  stores  a  specified  value  and  whether  a  PCR  contains  a  specified  value.  These 
authorization  policies  can  be  used  to  implement  data  sealing. 

Power  failure  counter  TPM  2.0  has  a  special  32-bit  NV  monotonic  counter  resetCount  that  can  be  mod¬ 
ified  by  the  TPM  only.  This  counter  is  incremented  on  a  power  failure,  and  thus  provides  a  count  of  the 
number  of  power  failures. 

Adversary  model  We  consider  an  adversary  that  controls  processes  that  reside  on  the  same  machine  as 
the  logging  process.  We  assume  that  the  adversary  never  controls  the  hardware,  i.e.,  she  cannot  snoop  on 


2 


electrical  signals,  or  conduct  side-channel  attacks  by  observing  physical  signals  like  power  consumption. 
We  distinguish  between  two  phases  of  a  system  that  runs  our  logging  infrastructure.  These  two  phases  are 
separated  by  the  event  that  the  adversary  takes  control  of  the  machine  by  gaining  root  privilege.  We  assume 
that  in  the  first  phase,  the  adversary  does  not  have  root  privileges. 


3  The  Basic  Protocol  (Protocol  A) 


In  this  section,  we  present  our  basic  protocol  (Protocol  A),  and  provide  informal  arguments  for  its  tamper¬ 
proofness. 


3.1  Protocol  Description 

Protocol  A  specifies  the  behavior  of  four  entities:  the  logger,  the  verifier,  the  TPM,  and  the  OS.  We  call 
each  entity  a  role  in  the  protocol.  We  explain  the  logger  program,  as  it  is  the  most  complex  component  and 
uses  novel  TPM  features.  We  briefly  discuss  the  verifier  program,  with  the  detailed  program  including  the 
OS  and  TPM  presented  in  Appendix  F. 

Logger  The  logger  uses  a  sequence  of  keys  (fcej/(0),  key key (n))  to  produce  HMACs  of  the  log  data, 
which  arrives  sequentially.  We  annotate  each  key  with  the  index  i  of  its  position  in  the  sequence.  The  key 
sequence  is  a  hash  chain  starting  with  secret  key{0),  which  is  a  secret  shared  between  the  logger  and  verifier. 
The  key  is  the  hash  of  the  n— 1*^  key:  key{n)  =  hash{key{n  —  1)). 

The  logger  has  four  phases:  startup,  logging,  shutdown,  and  verification. 

Startup  At  machine  startup,  a  sealed  key  object  (sealed  blob  containing  the  key)  is  stored  in  a  designated 
location  sKeyLoc  on  the  hard  disk.  This  blob  is  sealed  to  the  current  value  of  the  monotonic  TPM  counter. 
Initially,  the  first  sealed  key  object  for  key{0)  is  set  up  by  the  administrator.  Subsequent  sealed  key  objects 
are  stored  by  the  logger  during  shutdown. 

The  logger  first  acquires  locks  on  its  memory  locations,  the  disk  location  sKeyLoc  storing  the  sealed  key 
object,  and  the  disk  location  fileLoc  storing  the  log.  These  locks  prevent  any  attacker  without  root  privileges 
from  reading  from  and  writing  to  these  locations.  They  are  implemented  using  mechanisms  such  as  process 
memory  isolation  and  access  control  in  the  file  system.  On  a  system  restart,  these  locks  are  released.  Next, 
the  logger  unseals  the  sealed  key  object  to  obtain  the  current  key  and  then  increments  the  TPM  counter.  At 
this  point,  the  sealed  key  object  can  no  longer  be  unsealed. 

Logging  After  startup,  the  logger,  upon  receiving  new  log  data,  (1)  produces  an  HMAC  of  the  data  using 
the  current  key  key{k),  (2)  writes  the  log  data  and  HMAC  to  disk,  (3)  generates  key{k  +  1)  by  computing 
the  hash  of  the  old  key  key{k),  and  (4)  irretrievably  erases  the  old  key  from  the  RAM. 

The  logger  does  not  use  the  hash  chain  feature  that  TPM  offers  via  PCRs.  Instead,  it  computes  the  hash 
in  software,  which  vastly  improves  the  logger’s  performance,  because  hashing  in  memory  is  much  faster  than 
using  PCRs. 

Shutdown  Upon  receiving  a  shutdown  notification,  the  logger  finishes  processing  the  queue  of  logs,  and  then 
seals  the  current  key  to  the  current  monotonic  TPM  counter  value  and  writes  the  sealed  key  object  to 
disk.  This  phase  ensures  that  when  the  machine  starts  up  again,  there  is  a  sealed  key  object  stored  on  disk. 
Protocol  A  requires  the  shutdown  module  of  the  OS  to  guarantee  that  the  logger  is  able  to  finish  its  shutdown 
phase  before  the  machine  is  powered  off. 

Verification  The  verification  phase  is  triggered  by  a  verification  request  from  an  external  verifier;  a  nonce  is 
sent  with  such  a  request.  Upon  receiving  such  a  request,  the  logger  sends  back  the  log  entries  (log  data  and 
HMACs)  stored  on  disk,  and  the  HMAC  of  the  nonce  using  the  current  key. 

Verifier  The  verifier  initiates  the  verification  phase  by  sending  a  nonce  along  with  the  verification  request  to 
the  logger.  Upon  receiving  log  entries  containing  both  log  data  and  its  HMAC  and  the  HMAC  of  the  nonce 
using  the  last  key,  the  verifier  checks  the  HMAC  of  each  log  entry  and  the  HMAC  of  the  nonce.  The  verifier 
has  the  initial  shared  secret  and  can  generate  all  the  keys. 
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3.2  Informal  Argument  for  Tamper-proofness 

We  explain  informally  why  Protocol  A  satisfies  the  tamper-proofness  property.  Formal  analysis  of  Protocol  A 
is  presented  in  Section  5. 

We  refer  to  keys  that  have  smaller  indices  than  the  current  key  used  by  the  logger  as  old  keys.  The 
following  two  properties  hold:  (1)  an  attacker  cannot  learn  the  old  keys  and  (2)  without  the  old  keys,  the 
attacker  cannot  tamper  with  the  logs  generated  prior  to  the  attacker  gaining  root  privilege,  i.e.,  modify 
entries,  remove  entries,  and  truncate  the  log. 

Property  (1)  holds  both  before  and  after  the  attacker  gains  root  privilege.  Before  the  attacker  gains  root 
privilege,  the  memory  and  disk  locations  are  properly  protected.  When  the  attacker  gains  root  privilege,  it 
has  access  to  all  memory  and  disk  locations.  However,  old  keys  are  not  present  in  the  machine’s  memory  as 
the  logger  erases  these  keys  upon  generation  of  the  next  key.  The  sealed  key  objects  of  these  old  keys  cannot 
be  used  to  extract  keys,  because  these  sealed  key  objects  are  sealed  to  past  values  of  the  NV  monotonic 
counter  of  the  TPM  and  there  is  no  way  to  decrement  the  counter  value.  In  particular,  if  the  adversary 
deletes  the  monotonic  counter  (by  means  of  his  root  privilege),  then  any  new  monotonic  counter  will  start 
with  the  maximum  value  of  all  counters  that  ever  existed  on  the  TPM.  Finally,  the  keys  form  a  hash  chain, 
and,  therefore,  there  is  no  way  to  generate  the  old  keys  directly  from  the  current  key.  (2)  follows  directly 
from  (1)  and  the  property  of  HMACs:  without  the  correct  key,  an  attacker  cannot  generate  valid  HMACs 
that  pass  the  verification.  Tamper-proofness  follows  from  (1)  and  (2). 

4  Enhanced  Protocol  (Protocol  B) 

The  basic  protocol  (Protocol  A)  has  the  tamper-proofness  property,  but  is  not  very  practical.  Enhanced 
protocol  (Protocol  B)  uses  additional  mechanisms  to  satisfy  the  following  practical  requirements.  (1)  Hard 
disk  space  is  limited,  and,  thus,  logs  need  to  be  periodically  truncated.  (2)  Power  failures  may  not  permit  the 
logger’s  shutdown  phase  to  complete,  leading  to  the  loss  of  the  current  key.  The  protocol  needs  to  be  able  to 
recover  from  power  failures.  (3)  For  efficient  and  modular  enforcement  of  several  policies,  the  protocol  needs 
to  support  verification  of  an  arbitrary  subset  of  the  log  independently. 

4.1  New  Mechanisms 

Branched  key  chain  The  enhanced  protocol  evolves  keys  in  a  branched  manner.  Keys  are  divided  into 
epochs.  The  initial  keys  of  each  epoch  form  a  hash  chain  staring  from  key(0).  The  initial  key  for  epoch  k  is 
computed  as:  key(k)  =  hash{key{k  —  1)  |  "epoch”).  There  is  a  fixed  maximum  number  (E)  of  keys  within  an 
epoch.  These  keys  form  another  hash  chain  indexed  by  the  epoch  number  and  a  sub-epoch  number.  The 
sub-epoch  key  in  epoch  k  {key{k,i))  is  hash{key{k,i  —  1)  |  "subepoch!').  Here,  key{k,0)  =  key{k). 

Mapping  between  keys  and  log  entries  To  increase  the  flexibility  of  the  verification  and  relieve  the 
verifier  from  the  burden  of  deriving  key  indices  for  checking  HMACs,  we  incorporate  key  index  information 
into  the  log  data.  Each  log  entry  now  includes  the  log  data,  the  epoch  and  sub-epoch  indices  of  the  key 
producing  the  HMAC,  and  an  HMAC  of  the  log  data  and  the  key  indices. 

4.2  Protocol  Description 

Logger  The  logger  in  Protocol  B  cycles  through  the  same  phases  as  in  Protocol  A.  To  maintain  the  branched 
key  chain,  the  logger  starts  a  new  epoch  either  when  the  previous  epoch  is  completed  or  at  startup.  We  first 
describe  the  sub-routine  that  is  invoked  when  a  new  epoch  starts.  For  brevity,  we  omit  the  argument  of  the 
location  of  the  NV  counter  from  seal  and  unseal,  as  this  protocol  uses  only  a  fixed  monotonic  counter.  The 
pseudo  code  is  shown  in  Figure  1. 

New  epoch  In  this  sub-routine,  the  sealed  object  from  location  sKeyLoc  is  unsealed  to  obtain  the  current 
epoch  key.  Then,  the  next  epoch  key  is  computed  and  sealed  to  the  next  TPM  counter  value.  Finally,  the 
TPM  counter  is  incremented  and  the  epoch  and  sub-epoch  counters  are  set  appropriately. 

A  power  failure  that  occurs  in  the  middle  of  the  new  epoch  routine  could  create  a  discrepancy  between 
the  TPM  monotonic  counter  value  and  the  value  that  the  sealed  blob  on  disk  is  sealed  to.  If  the  power 
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NewEpoch  Sub-routine 
epochkey  unseal  {data,  in  sKeyLoc) 

if  unseal  fails  then 
L  return  fail; 

nextepochkey  hash{epoehkey  \  “epoeh”) 

n  read  TPM  counter 

sKeyLoc  <r-  seal{nextepoehkey,  n  -I-  1) 

increment  TPM  counter 

key t—  epochkey 

epoeh  t—  n;  subepoch  t—  0 

Startup  Phase 

lock  all  required  memory  locations 
start  newepoch  phase 
if  failure,  increment  TPM  counter 
start  newepoch  phase 
if  successful,  notify  the  OS 


Logging  Phase 

while  no  shutdown  notification  do 
data  t—  get  log  data 
logentry  t—  {data\  epoch\  subepoch, 
hmac{data\epoch\ subepoch,  key)) 
increment  subepoeh 
key  t—  hash{key  \  “subepoch") 
write  logentry  to  disk 
if  subepoch  =  E  then 
|_  start  newepoch  phase 

start  shutdown  phase 

Shutdown  Phase _ 

wait  for  log  producer  to  stop 
while  message  queue  is  not  empty  do 
|_  process  data  as  in  logging  phase 
finaldata<r-  hash{key  \  shutdown) 
process  finaldata  as  in  logging  phase 


Fig.  1.  Programs  for  Protocol  B,  not  including  the  verifier  stage 


failure  occurs  right  after  the  instruction  that  writes  the  sealed  blob  to  disk  and  before  the  TPM  counter  is 
incremented,  the  TPM  counter  value  will  be  one  step  behind  the  value  that  the  sealed  blob  is  sealed  to.  The 
startup  phase  handles  this  situation. 

Startup  Similarly  to  Protocol  A,  the  logger  locks  critical  locations  in  memory  and  on  disk  (and  releases  them 
on  a  restart).  Next,  it  invokes  the  new  epoch  sub-routine.  Depending  on  whether  the  previous  power-off  is  a 
clean  shutdown  or  a  power  failure,  the  sealed  blob  stored  on  the  hard  disk  at  startup  is  sealed  to  either  the 
current  value  of  the  monotonic  TPM  counter  or  that  value  incremented  by  one.  If  the  new  epoch  sub-routine 
fails  to  unseal  the  key,  then  TPM  counter  is  incremented  and  the  new  epoch  sub-routine  is  called  again. 
Logging  The  logger  computes  keys  in  the  branched  key  chain.  It  computes  a  new  sub-epoch  key  for  each  new 
log  entry  until  the  maximum  sub-epoch  number  is  reached.  At  this  point,  a  new  epoch  key  is  computed  by 
invoking  the  new  epoch  sub-routine.  For  each  log  entry,  the  logger  places  the  epoch  and  sub-epoch  indices 
in  the  log  to  build  an  explicit  mapping  between  log  entries  and  keys. 

Shutdown  In  the  shutdown  phase,  all  remaining  log  entries  are  processed.  Unlike  protocol  A,  the  logger  does 
not  create  a  sealed  blob  for  the  current  key,  as  this  has  been  done  inside  each  new  epoch  sub-routine  during 
logging.  Instead,  it  writes  a  special  log  entry  hash{key  \  shutdown)  to  disk  indicating  the  completion  of  a 
clean  shutdown.  The  absence  of  such  an  entry  at  machine  startup  is  the  evidence  of  a  power  failure. 
Verification  The  verification  phase  of  the  logger  is  the  same  as  protocol  A,  except  for  the  deletion  of  logs 
after  each  successful  verification  and  attestation  of  the  resetCount  value  in  TPM.  The  verifier  sends  a  ticket 
containing  encrypted  information  about  how  many  epochs  have  been  verified.  The  logger  stores  this  ticket 
on  disk  and  sends  this  ticket  back  to  the  verifier  along  with  log  entries  in  response  to  the  next  verification 
request. 

Verifier  Differently  from  protocol  A,  the  verifier  starts  by  asking  for  the  value  of  resetCount  to  determine  if 
there  was  a  power  failure.  The  verifier  additionally  generates  a  ticket  attesting  to  the  successful  verification 
up  to  a  check  point  for  the  logger.  The  verifier,  after  verification  till  epoch  k  (the  last  verified  epoch),  sends 
a  ticket  to  the  logger  stating  that  the  verification  till  epoch  k  is  successful.  The  ticket  is  an  encryption: 
encvfik  \  r),  where  k  is  the  last  verified  epoch,  r  is  a  nonce  known  only  to  the  verifier  and  V  is  the  public 
key  of  the  verifier.  The  ticket  is  sent  to  the  verifier  in  the  next  verification  phase  along  with  log  entries  from 
epoch  k  +  1.  The  verifier  uses  the  information  from  the  ticket  sent  by  the  logger  to  jump  to  the  appropriate 
epoch  key  to  start  the  verification. 

The  verifier’s  pseudo  code  is  shown  in  Figure  2.  The  verifier,  upon  receiving  the  log  and  the  ticket, 
decrypts  the  ticket  to  obtain  the  epoch  index.  If  the  ticket  is  valid,  the  verifier  computes  the  sub-epoch  key 
and  begins  verification.  In  the  end,  the  verifier  generates  a  new  ticket  and  sends  it  to  the  logger.  It  is  also 
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Verification  Phase _ 

attest  to  resetCount. 
nonce  <r-  recv  from  verifier 
fhmac  hmac(nonce,  key) 
log  •<—  read  whole  log 
tct  -ir-  read  ticket 
send  {jfim,  log,  let)  to  verifier 
recv.  {st,  tct,  del)  from  verifier 
if  st  =  1  then 
save  tct  to  disk 
delete  epochs  till  del 


Verifier  Program 
ask  for  attestation  of  resetCount 
powfail  current  resetCount  ^  old  resetCount 
nonee,  r  generate  nonces 
send  nonce  to  logger 

{fhm,log,  encv{n\r'))  recv  from  logger 
check  r'  is  nonce  used  in  last  ticket,  halt  if  not 
epochkey  hashC  [sharedsecret\  epoch!') 
logavailable  -h-  true;  idx  0 
while  logavailable  do 

key  -ir-  epochkey,  n  n  +  1 
for  j:  0  to  E-1  do 

if  no  more  log  entries  then 
|_  logavailable  false;  break 

verifYhma,c{log{idx)data,  log{idx)^ac,  key) 
if  log  entry  data  is  “shutdown”  then 
L  break 

idx<—  idx+  1;  key hash{key\“ subepoch") 
epochkey  hash{epochkey\  “epoch") 
verif  yhmac(nonce,  fhm,  key) 
if  all  verifyhmac  pass  and  not  powfail  then 
|_  send  (1,  encv{n  —  l|r),  n  —  1)  to  logger 


Fig.  2.  Verification  stage  programs  for  Protocol  B 


easy  to  modify  the  verifier  to  verify  any  subset  of  the  log  by  making  use  of  the  epoch  and  suhepoch  indices 
contained  in  each  log  entry. 


4.3  Improvements  to  the  Logging  Infrastructure 


We  highlight  how  the  extensions  to  the  protocol  address  the  practical  concerns  that  we  summarized  at  the 
beginning  of  this  section. 

Rolling  logs  Using  the  ticket,  the  logger  can  delete  logs  up  to  a  verification  check  point.  Instead  of  sending 
the  entire  log  starting  from  the  first  log  entry,  the  logger  only  needs  to  send  the  ticket  for  the  first  k  epochs 
and  the  log  starting  from  the  fc+1  epoch.  To  further  lower  the  requirement  of  disk  space  for  storing  the 
HMACs  of  logs,  it  is  possible  to  store  a  hash  of  all  HMACs  in  an  epoch  after  the  completion  of  the  epoch, 
instead  of  storing  each  HMAC. 

Recovery  from  power  failure  A  power  failure  may  prevent  the  logger  from  completing  the  shutdown 
phase  and  storing  the  current  key  to  disk.  As  a  result,  the  logger  in  Protocol  A  has  no  way  of  deriving  the 
valid  key  at  the  next  startup  without  help  from  a  remote  server.  The  branched  key  chain  used  in  Protocol  B 
offers  a  means  to  recover  from  such  a  loss.  Dividing  the  keys  into  epochs  allows  the  logger  to  periodically 
store  the  sealed  blob  of  the  next  epoch  key  to  disk  without  sacrificing  performance.  Upon  rebooting  after  a 
power  failure,  the  logger  simply  increments  the  TPM  counter  to  retrieve  the  key  from  disk. 

Portions  of  the  log  buffered  in  memory  that  are  not  written  to  disk  due  to  a  power  failure  are  lost. 
However,  a  power  failure  can  be  detected  by  the  verifier  by  checking  the  value  of  TPM’s  resetCount  counter. 

Modular  log  analysis  With  the  epoch  and  sub-epoch  indices  stored  with  each  log  entry,  the  verifier  can 
request  the  logger  to  send  portions  of  the  log  entries  that  it  wants  to  verify.  One  application  is  enforcing 
multiple  policies  on  the  same  system  modularly.  Each  policy  analysis  can  select  relevant  portions  of  the  log 
and  perform  the  verification  independently;  as  the  verifier  can  compute  the  keys  based  on  the  epoch  and 
subepoch  information  contained  in  each  log  entry. 


6 


4.4  Design  Choices  and  Limitations 


Power  attacks  One  limitation  of  our  infrastructure  is  that  we  cannot  distinguish  genuine  power  failures 
from  adversarial  system  crashes.  An  attacker  can  hide  malicious  activities  before  the  power  failure  because 
log  entries  buffered  in  memory  are  lost.  Existing  logging  schemes  that  use  volatile  memory  for  buffering 
logs  [1]  or  even  work  in  verifiable  computation  [11]  suffer  from  the  same  problem.  Our  choice  of  using  volatile 
memory  for  log  buffering  is  driven  by  the  desire  to  accommodate  high-frequency  logging.  Accesses  to  non¬ 
volatile  memory  (hard  disk  or  TPM)  are  slow;  thus,  it  is  not  feasible  to  use  them  to  process  each  log  entry. 
Additional  hardware  support  could  mitigate  this  problem. 

Tradeoffs  between  performance  and  security  guarantees  Disk  write  operations  are  expensive,  and, 
therefore,  the  bigger  the  size  of  the  buffered  log  entry  blocks,  the  more  efficient  the  logger  program  becomes. 
However,  in  case  of  a  power  failure,  the  logger  loses  the  log  entries  buffered  in  memory,  which  may  record 
adversary  actions.  Consequently,  the  security  guarantee  becomes  weaker  as  the  block  size  increases.  This 
problem  is  mitigated  in  protocol  B  by  allowing  offline  recovery  from  a  power  failure  and  detection  of  the 
power  failure. 

Another  tradeoff  lies  in  our  decision  to  hash  keys  in  RAM  instead  of  the  TPM  to  accommodate  high- 
frequency  log  updates.  A  potential  issue  is  that  non-root  processes  may  coerce  a  root  process  to  write  the 
memory  to  disk,  e.g.,  by  stressing  the  system  memory,  and  thus  leak  the  keys.  Special  precaution  need  to  be 
taken  to  protect  memory  regions  that  store  the  keys,  which  we  leave  for  future  work. 

Suggested  hardware  features  to  defend  against  power  attacks  One  way  to  prevent  power  attacks  is 
to  rely  on  hardware  support  to  allow  for  a  clean  shutdown  in  spite  of  a  power  failure.  One  possibility  is  to 
provide  a  “fast”  memory  interface  for  NV  memory  of  the  TPM  with  assured  write  on  a  power  failure.  The 
logger  uses  the  NV  memory  as  a  buffer  instead  of  the  RAM.  The  logger  always  maintains  an  entry  composed 
of  a  string  “power  failure”  and  its  HMAC  using  the  current  key.  This  last  log  entry  is  never  written  to 
disk,  except  after  recovering  from  a  power  failure  when  the  TPM  NV  memory  content  is  flushed  to  disk. 
An  attacker  cannot  generate  the  last  entry  on  its  own,  so  tampering  with  entries  stored  in  the  TPM  NV 
memory  can  be  detected.  This  scheme  requires  the  logger  to  compute  an  additional  HMAC  for  every  log 
entry.  However,  software  HMAC  is  very  fast  and  is  unlikely  to  be  a  performance  bottleneck. 


5  Verification 


We  augment  the  modeling  language  and  program  logic  from  an  existing  work  [12, 13]  and  formally  prove  that 
Protocol  A  satisfies  the  tamper-proofness  property.  Protocol  B  uses  similar  techniques  to  ensure  tamper¬ 
proofness,  so  the  verification  results  of  Protocol  A  can  be  straightforwardly  extended  to  Protocol  B.  A 
detailed  formal  description  of  verification  is  present  in  the  appendix. 

System  modeling  We  assume  the  system  has  a  set  of  principals  V  and  there  is  a  partial  order  on  the 
principals:  we  write  A  ^  V  if  V  is  more  privileged  than  X,  i.e.,  can  access  all  the  resources  that  X  can.  We 
write  root  to  denote  the  root  and  tpm  to  denote  TPM.  {V,  <)  is  an  access  control  lattice,  where  the  maximal 
elements  are  root  and  tpm. 

The  system  is  modeled  as  several  components,  which  we  call  threads,  running  concurrently.  Each  thread 
is  owned  by  a  principal.  Threads  share  several  common  data  structures,  which  include  storage  (RAM  and 
disk)  and  read  and  write  locks  on  storage.  The  logger,  veriher,  OS,  and  TPM  are  encoded  using  our  modeling 
language.  Other  threads  (including  adversary)  in  the  system  are  modeled  as  arbitrary  programs  interacting 
with  the  rest  of  the  system.  Their  behavior  is  constrained  by  our  adversary  model,  which  is  specified  by 
predicates  stating  a  principal’s  knowledge  based  on  what  it  has  learned  so  far.  For  instance,  a  principal  can 
compute  the  HMAC  of  d  using  key  k  if  it  has  both  the  data  and  the  key.  This  resembles  Dolev-Yao’s  network 
adversary. 

The  behavior  of  the  system  is  captured  by  the  set  of  traces  generated  by  all  possible  interleaving  executions 
of  the  threads.  The  security  property  is  specified  as  a  first-order  logic  formula  that  holds  on  every  trace  of 
the  system.  The  model  and  language  is  discussed  in  more  details  in  Appendix  A. 
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Predicates  We  define  the  predicates  used  in  the  verification.  Action  predicates,  summarized  below,  describe 
the  semantics  of  actions  such  as  read  and  write,  with  @  u  denoting  the  time  u  when  the  predicate  holds. 

Read(i,  I,  m)@u  :  thread  i  reads  m  from  location  I 

Write(i,  I,  m)@u  :  thread  i  writes  m  to  location  I 

Hmac(i,  d,  I,  m)@u  :  thread  i  produces  m  =  hmac{d,  k) 

where  key  k  is  stored  in  location  I 
VerifyHmac(i,  m,  d,  k)@u  :  thread  i  verifies  m  =  hmac{d,  k) 

Other  key  predicates  used  in  the  verification  are  shown  below. 

Mem(l,  m)@u  :  location  I  has  value  m 

CanRead(z,  l)@u  :  i  can  read  location  I 
lsReadLocked(i,  :  thread  i  holds  the  read  lock  of  I 

,  X,  e)@u  :  thread  i  owned  by  X  runs  expression  e 

Has(i,  s)@u  :  thread  i  knows  s 

Owner(i,  K)  :  principal  K  owns  thread  i 

Contains(TO,  m! ,  S)@u  :  m'  can  be  derived  from  m  using  S 
MayDerive(e,  e',  S)  :  e'  can  be  derived  from  e  using  S 

The  Contains(m,  m'.  S')  predicate  is  true  when  the  term  m!  can  be  extracted  from  m  using  elements  of 
the  set  S;  for  instance,  m  is  an  encryption  of  m!  using  a  key  k  and  S  contains  the  key  k.  It  is  defined 
with  respect  to  an  inductively-defined  predicate  MayDerive  (details  in  Appendix  C).  One  example  rule  is 
that  MayDerive(e,  hash{e),  S)  is  true  without  any  premises:  from  a  term  e,  its  hash  can  always  be  computed. 
Predicate  Has(z,  s)  is  true  if  thread  i  has  the  plain  text  of  s.  It  is  defined  using  Contains:  i  has  s  if  there 
exists  a  term  m  that  contains  s,  and  thread  i  receives  m  or  reads  m  from  the  storage.  These  predicates  state 
the  assumptions  that  cryptographic  functions  are  correct  and  thus  capture  the  adversary’s  capabilities.  We 
present  the  details  of  the  logic  in  Appendix  B  and  detailed  definitions  of  predicates  in  Appendix  C. 

Axioms  about  actions  Our  proof  also  uses  sound  axioms  specifying  the  semantics  of  actions.  We  show 
the  axioms  for  generating  and  verifying  HMACs  below.  Axiom  Ai  states  that  on  successful  verification,  it  is 
the  case  that  someone  must  have  produced  the  HMAC  with  a  key  stored  in  location  1.  Axiom  A2  states  that 
if  a  thread  j  computes  a  HMAC  using  a  key  key  based  on  location  /,  it  must  be  the  case  that  j  can  read 
1.  Similar  to  the  Has  predicate,  these  axioms  also  state  assumptions  about  the  correctness  of  cryptographic 
functions.  Other  axioms  are  listed  in  Appendix  E. 

Ai  Vi,  mac,  d,  key,  u.  VerifyHmac(i,  mac,  d,  key)  @  u  D 

3j,  I,  u'.{u'  <  u)  A  HmacQ',  d,  I,  mac)  @  u'  A  Mem(?,  key)  @  v! 

A2  Vj,  mac,  d,  key,  u.  Hmac(j,  d,  I,  mac)  @  u  D  CanRead(j,  1)  @  u 

System  assumptions  System  assumptions  are  specified  as  axioms  as  well.  We  define  three  axioms  for 
this:  one  specifies  the  capability  of  the  forward-integrity  adversary,  one  specifies  an  assumption  about  the 
processes  running  during  the  logger’s  startup  phase,  and  one  specifies  the  effect  of  the  access  control  lattice. 
We  write  Ua  to  denote  the  time  when  the  adversary  gains  root  privilege. 

The  following  axiom  specifies  that  before  time  Ua,  processes  owned  by  root  are  well-behaved  and  do  not 
interfere  with  the  logger.  Predicate  RW(i,  L)@u  is  true  if  thread  i  reads  from  or  writes  to  any  location  in  the 
set  L  at  time  u.  The  axiom  states  that  processes  owned  by  root  do  not  access  any  of  the  storage  locations 
owned  by  the  logger  (specified  as  LoggerLoc),  and  only  threads  running  with  the  privilege  of  the  OS  can 
access  locations  shared  between  the  OS  and  the  logger  (specified  as  LoggerOSLoc). 

Aadv  =  Vu  <  Ua-  NoAdv(M) 

NoAdv(M)  =  Vz.  Owner(z,  root)  @  uD  (VT.  LoggerLoc(T)  D  ^RW(z,  L)  @  u) 

A(VL.LoggerOSLoc(L)  A  RW(z,L)  @  u  A)  HT(i,  root,  OS)  @  u) 

Axiom  Af^fji  states  that  before  the  machine  is  compromised,  after  any  reset,  no  thread  reads  and  unseals 
the  sealed  key  before  the  logger  increments  the  TPM  counter.  Predicate  Early(t6)  is  true  if  u  is  a  time  point 


between  a  reset  and  the  logger  incrementing  the  TPM  counter  and  there  are  no  other  resets  or  counter 
incrementing  operations  between  them. 

Anr  =  Vm,  i,  m.  Early(M)  A  (m  <  Ua)  A  ^HT(i,  L,  LOGGER)  @  u 
D  ^Read{i,  M.disk.sKeyLoc,m)  @  u 

This  may  seem  to  be  a  strong  assumption;  however,  verifying  that  it  holds  on  a  real  system  is  feasible.  We 
discuss  this  further  at  the  end  of  this  section. 

The  protection  provided  by  the  access-control  lattice  to  guard  sensitive  operations  is  captured  using 
axioms  similar  to  the  one  shown  below,  which  specifies  the  effects  of  the  lattice  on  memory  read  accesses. 

ARDLattice  =  Vz,  j,  u,  I,  I,  K.  lsReadLocked(z,  1)  @  u  A  Owner(z,  I)  A  I  A  K  A 

Owner(j,  X)  D  CanRead(j,  I)  @  u 

If  a  location  I  is  locked  by  a  thread  z  owned  by  principal  I,  then  any  thread  j  owned  by  a  principal  K 
higher  than  I  on  the  access  control  lattice  can  read  1. 

Verification  goal  We  define  an  auxiliary  predicate  LastLogldx(A:,  u,  Uend)  to  state  that  before  time  Uend,  the 
last  log  entry  the  logger  writes  is  indexed  by  k,  and  written  at  time  u.  We  write  7  to  denote  the  context 
containing  all  the  axioms  introduced  so  far.  The  main  result  of  our  verification  is  a  derivation  of  the  following 
judgment: 

7  hVfc,  k\  Ub,  Ue,  ui,Ur,  Uw,  i,j,  log,  n,fhm.  HT(z,  V,  VERIFIER)  on  [ub,  Ue]  A 
{ub  <  Uc  <  Ur  <  Uv  <  Ue)  A  Send(z,  VERIFY)@Ub  A  New(z,  nonce)@Uc  A 
Recv(z,  {log[n],n,fhm))  @  Ur  A  VerifyHmac(z, /Tizn,  nonce,  key{n  +  l))@zz„  A 
((zZr  <  Ua)  D  LaStLogldx(A:,  ZZp  ZZr))  A  ((zZr  >  Ua)  E)  LaStLogldx(fc,  ZZ/,  ZZa))  A 
(1  <  fc'  <  fc)  A  {ui  >  Uyj)  A  V\/nte{j,fileloc{k'),v)  @  Uw 
A  HT(_),  L,  logger)  @  Uw  ^  data{v)  =  data{log{k')) 

It  says  that  if  the  verifier  completes  successfully  then  for  the  log  data  received  by  the  verifier  at  time  Ur, 
the  received  data  at  index  k'  is  the  same  as  the  log  data  v  that  was  written  to  disk  by  the  logger  at  index 
k' ,  conditional  on  the  assumption  that  k'  was  written  to  disk  by  the  logger  before  time  min(zzr,  Ua)-  In  other 
words,  the  log  entries  written  before  the  adversary  took  control  at  time  Ua  will  not  pass  verification  if  they  are 
tampered  with.  The  formula  to  the  right  of  the  h  is  the  formal  definition  of  the  tamper-proofness  property. 
The  detailed  derivation  steps  are  provided  in  Appendix  E.  Here  we  provide  an  outline  of  the  derivation. 

Derivation  steps  The  proof  of  the  tamper-proofness  property  relies  on  the  following  four  invariants.  Pred¬ 
icate  keyOwnerln(zz)  states  that  at  time  u  only  the  logger,  TPM,  and  verifier  have  the  key.  keyMemln(zz) 
states  that  at  time  u  the  only  locations  that  may  have  the  key  reside  in  the  memory  owned  by  the  logger, 
or  the  memory  shared  between  the  logger  and  the  TPM,  or  the  disk  location  that  contains  the  sealed  key 
object.  Predicate  oldKeyAdv(zz,  zza)  states  that  at  time  u,  no  thread  other  than  the  logger,  TPM,  or  verifier 
has  an  old  key  (key  used  before  time  Ua)-  Finally,  predicate  oldKeyNotlnMem(zz, Ua)  states  that  at  time  u, 
no  memory  location  contains  an  old  key  (key  used  before  time  Ua)- 

1.  Vzt. zz  <  zZa  E  keyOwnerln('u)  3.  Vzz.zz  >  zzo  E  oldKeyAdv('u,  zzo) 

2.  Vzz.zz  <  zZa  E  keyMemln(zz)  4.  Vzz.zz  >  zzo  E  oldKeyNotlnMem(zz,  zzo) 

The  proofs  of  these  invariants  use  transfinite  induction  on  time;  given  the  invariants  hold  before  time  u, 
we  prove  that  they  hold  at  u.  In  particular,  we  use  the  program  logic  to  reason  about  the  protocol  roles  to 
show  that  these  invariants  are  maintained  when  programs  belonging  to  these  roles  execute  in  an  adversarial 
environment. 

From  (I)  and  (2),  we  can  prove  that  the  adversary  does  not  have  access  to  any  valid  keys  generated 
before  time  Ua  at  any  time  prior  to  Ua-  (3)  and  (4)  imply  that,  after  Ua,  the  adversary  cannot  obtain  keys 
that  were  generated  prior  to  time  Ua-  From  the  above,  we  can  conclude  that  at  no  time  does  the  adversary 
possess  keys  used  by  the  logger  prior  to  time  Ua-  Then,  it  can  be  shown  that  the  adversary  cannot  produce 
valid  log  entries  generated  before  time  Ua,  which  is  the  desired  tamper-proofness  property. 

Design  decisions  based  on  verification  One  important  system  assumption  that  the  tamper-proofness 
property  depends  on  is  Ajvz?:  at  any  time  (before  the  adversary  gets  root  access)  between  the  machine  startup 
and  the  logger  startup,  no  process  should  read  the  sealed  blob  on  disk.  The  fact  that  the  logger  starts  soon 
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Block 

size 

Total 
time  (ms) 

Disk 
time  (ms) 

512 

5,135 

2,513 

256 

6,675 

4,056 

128 

11,074 

8,320 

64 

15,882 

12,997 

32 

29,148 

25,505 

16 

53,306 

49,168 

Table  1.  Time  to  log  100,000  entries  with  varying 
block  size. 


Log  size 

#log  entries 

Verif. 
time  (s) 

175MB 

1,211,168 

27 

390MB 

2,684,760 

61 

736MB 

5,075,958 

116 

1.48GB 

10,198,014 

234 

Table  2.  Time  (in  seconds)  to  verify  logs  in  a  serial 
manner 


after  machine  startup  after  a  reset  makes  the  number  of  running  threads  during  that  period  of  time  small. 
The  remote  attestation  feature  of  the  TPM  can  be  used  to  check  that  A jvi?  holds  by  verifying  the  code  that 
runs  on  system  reset.  This  assumption  leads  to  important  design  decisions  of  the  logger.  For  example,  to 
satisfy  this  assumption,  the  logger  cannot  be  implemented  as  a  user-level  application.  It  would  be  extremely 
difficult  to  ensure  the  tamper-proofness  property  of  such  a  design,  because  the  logger  may  not  be  the  first 
user  application  to  start  and  other  user  applications  starting  before  the  logger  cannot  be  trusted. 

Several  axioms  (e.g.,  AnDj^attice)  capture  the  requirements  of  access-control  lattice.  For  these  axioms  to  be 
sound  in  reality,  we  need  to  ensure  that  the  implemented  access  control  mechanisms  are  correct  and  cannot 
be  compromised  by  threads  not  owned  by  root.  For  instance,  we  use  process  isolation  to  protect  logger-owned 
memory  locations. 


6  Implementation  and  Evaluation 

Implementation  We  implement  a  prototype  logger  and  verifier  based  on  Protocol  B.  Our  logger  application 
is  a  user-level  Windows  service  that  uses  the  ETW  logging  framework  of  Windows  7  to  receive  events  from 
applications  and  log  them.  Our  implementation  relies  on  the  assumption  that  services  in  Windows  are  trusted 
(see  the  discussion  in  Section  5) .  However,  we  need  not  trust  any  user- level  application  because  services  start 
before  these  applications.  We  use  keys  and  HMACs  of  256  bits  and  use  SHA256  to  produce  keys.  A  64-bit 
NV  memory  location  is  designated  as  the  monotonic  counter  that  keys  are  sealed  to. 

We  used  a  2.8GHz  quad  core  machine  with  6GB  of  RAM.  We  use  a  TPM  2.0  simulator  that  opens  two 
network  ports  to  receive  binary  TPM  commands  and  return  appropriate  responses  after  processing  those 
commands.  The  TPM  simulator  is  built  from  the  TPM  2.0  specs  and  models  all  TPM  2.0  functionality.  We 
also  use  a  C#  TPM  library  that  offers  an  easy  interface  to  the  TPM. 

The  most  significant  challenge  that  we  faced  in  the  implementation  was  that  high-level  languages  that  use 
garbage  collectors  do  not  usually  provide  language  support  for  secure  erasure  of  memory  objects,  because  the 
memory  manager  (garbage  collector)  moves  objects  around.  Though  G^  offers  pinning  of  memory  that  can 
be  used  to  securely  erase  memory,  the  use  of  G^  libraries  that  do  not  pin  memory  makes  securely  erasing  keys 
extremely  difficult.  However,  the  tamper-proofness  property  requires  secure  erasure  of  the  memory  objects 
that  store  the  keys.  Hence,  we  implement  an  intermediate  layer  in  C  such  that  the  current  key  always  lives 
in  the  memory  of  the  C  process.  This  C  process  uses  the  TPM  library  to  interact  with  the  TPM.  Also,  to 
avoid  unexpected  behavior  due  to  compiler  optimizations  we  used  SecureZeroMemory,  which  is  a  guaranteed 
way  of  setting  memory  in  Microsoft’s  version  of  C. 

Our  implementation  relies  on  the  process  memory  isolation  provided  by  the  operating  system  to  imple¬ 
ment  locks  on  volatile  memory  to  prevent  an  attacker  from  gaining  access  to  the  key  during  startup  phase. 
We  rely  on  user  privilege  access  control  to  implement  locks  on  disk. 

The  prototype  system  was  stable  across  clean  shutdowns  and  power  failures. 

Evaluation  Table  1  shows  the  logger’s  log-processing  time  given  different  block  sizes.  As  the  block  size 
grows,  the  processing  time  decreases,  and  so  does  the  percentage  of  disk  time  over  the  total  processing  time. 
This  shows  that  the  bigger  the  block  size,  the  more  efficient  the  logging  process.  However,  the  system  becomes 
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less  secure  as  block  size  increases;  the  attacker  has  a  better  chance  of  hiding  its  activities  in  buffered  logs 
that  will  be  discarded  after  a  power  failure. 

Our  storage  overhead  for  HMACs  for  approximately  32  million  log  entries  is  1  GB.  If  we  store  hashes  of 
HMACs  in  an  epoch,  then  with  an  E  value  (sub-epoch  number)  of  1000,  the  storage  overhead  of  32  billion 
log  entries  is  1  GB.  Thus,  the  storage  overhead  of  the  HMACs  is  not  a  bottleneck.  Further,  with  periodic 
verification,  log  entries  can  be  removed  frequently. 

Table  2  shows  the  evaluation  results  of  the  verifier’s  performance.  Verification  is  reasonably  fast,  even 
with  simple  sequential  verification.  We  expect  a  huge  speed  up  if  the  verification  process  is  parallelized  using 
pre- computed  keys. 


7  Related  Work 

Secure  logging  schemes  Auditing  has  been  studied  extensively;  for  example,  in  the  context  of  detecting 
misconfiguration  in  access  control  policies  [14,15],  and  in  the  context  of  holding  agents  accountable  for 
their  actions  [16].  Security  guarantees  provided  by  these  systems  are  based  on  the  assumption  that  logs  are 
tamper-proof. 

Most  closely  related  to  our  approach  is  work  by  Kelsey  and  Schneier  [1, 17].  They  also  use  a  hash  chain  of 
keys  to  ensure  the  integrity  and  confidentiality  of  logs.  Our  main  improvement  over  theirs  is  that  we  support 
continuous  logging  across  machine  restarts,  which  they  do  not.  Our  protocol  allows  truncation  of  logs  after 
verification.  As  we  only  care  about  integrity  of  log  entries,  our  scheme  is  much  simpler  than  theirs,  and 
therefore  allows  for  faster  log  appending  operations.  They  additionally  study  variants  of  untrusted  verifier, 
which  we  do  not  consider.  It  is  straightforward  to  extend  our  protocol  using  the  ideas  introduced  by  Kelsey 
and  Schneier  to  lift  the  assumption  that  the  verifier  is  trusted.  Follow-up  work  [18, 19]  does  not  tackle 
the  issues  we  address  in  this  paper,  and  instead,  focuses  on  making  the  encrypted  log  searchable  [18]  or 
implementing  the  scheme  [19].  Recent  work  addresses  the  issue  of  log  deletion  required  by  law  [6]  and  uses 
similar  scheme  as  [1, 17],  but  does  not  work  across  system  restarts  and  lacks  formal  verification. 

Monotonic  counters  have  been  used  to  ensure  the  tamper-proofness  of  logs  [2, 8,  7] .  They  use  the  monotonic 
counter  inside  the  attestation  of  each  log  entry,  whereas  we  use  a  software-based  hash  chain  of  keys  to  generate 
attestations  for  log  entries  and  only  use  the  counter  on  system  startup/shutdown  to  ensure  the  continuity  and 
secrecy  of  the  keys.  More  concretely,  we  seal  the  current  key  to  the  counter  value  using  the  TPM.  The  sealed 
blob  is  unrecoverable  after  the  counter  increments.  Thus,  we  create  use  and  discard  blobs,  which  is  a  novel 
use  of  the  monotonic  counter.  Because  we  do  not  use  the  TPM  in  normal  logging  activities,  our  log  appending 
operation  is  much  faster  than  that  in  prior  work.  In  the  best  case,  our  scheme  appends  approximately  20, 000 
log  entries  per  second  using  a  Intel  2.8GHz  processor  with  6GB  RAM  (Table  1),  much  faster  than  prior 
similar  schemes  [3,2, 19, 1,8,7].  The  best  of  these  schemes  can  process  1750  entries  per  second  using  Intel 
Gore  2  Duo  2.4GHz  GPU  with  4GB  of  RAM  [3].  A2M,  another  work  on  secure  logging  that  precedes  Trine, 
stores  logs  in  trusted  memory  [4] .  Due  to  the  limited  size  of  trusted  memory,  this  scheme  is  not  practical  to 
be  used  to  protect  logs  on  the  order  of  gigabytes,  which  our  work  aims  to  support. 

There  has  been  much  work  on  designing  efficient  data  structures  for  storing  logs  along  with  auxiliary 
information  (such  as  a  hash  tree)  to  provide  guarantees  of  tamper-proofness  [20-22,3,5].  For  instance,  the 
work  by  Grossby  et  al.  [3]  provides  a  dynamic  history  tree  data  structure  to  store  the  log  and  capture  the 
history  of  log  insertions  through  commitments.  These  structures  require  publishing  the  updated  state  of 
the  auxiliary  data  structure  quite  frequently;  e.g.,  after  each  log  addition.  However,  in  our  scenario,  external 
communication  may  not  be  feasible  given  the  high  bandwidth  requirement  of  logs  generated  at  high  frequency. 
While  these  schemes  are  effectively  online  schemes,  our  scheme  provides  the  forward  integrity  guarantee  in  an 
offline  manner,  even  if  the  verifier  does  not  verify  before  the  adversary  takes  control.  Also,  our  infrastructure 
is  able  to  append  logs  at  much  faster  rate  due  to  the  simplicity  of  our  approach. 

Other  schemes  that  use  trusted  hardware  TPMs  have  been  used  extensively  to  design  schemes  that 
guarantee  some  form  of  trust  in  computing  devices,  in  spite  of  malicious  software  running  on  the  device  [23,  24, 
11].  We  use  the  TPM  to  protect  a  key  by  producing  a  sealed  object  of  the  key  that  can  only  be  unsealed  when 
the  TPM’s  monotonic  counter  has  a  specific  value.  Incrementing  the  counter  makes  the  object  unscalable  by 
this  TPM  in  the  future. 
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Due  to  practical  constraints,  such  as  size,  power  consumption  and  cost,  the  TPM  is  limited  in  its  function¬ 
ality,  e.g.,  small  non-volatile  memory  that  degrades  with  about  100,000  writes.  An  ideal  hardware  solution 
for  tamper-proof  logging  is  trusted  secure  hardware  that  stores  the  whole  log  itself,  guaranteeing  not  only 
detection  of  tampering  but  also  recovery  of  the  tampered  logs.  Other  hardware  like  iButtons  [25]  has  been 
used  in  secure  logging  [19]  that  implements  the  scheme  of  Kelsey  and  Schneier  [1].  While  they  provide  many 
of  the  guarantees  that  our  scheme  can,  they  do  not  address  the  issue  of  auditing  across  power  cycles,  and 
their  implementation  is  slow  in  appending  log  entries  (~1  second  for  an  append). 

The  challenge  of  distinguishing  power  failures  from  malicious  power  attacks  that  we  face  is  also  encoun¬ 
tered  in  another  work  using  the  TPM  for  secure  code  execution  [11].  A  trusted  power  source  or  a  fail-safe 
power  failure  mechanism  is  needed  to  allow  TPMs  to  shutdown  cleanly  in  case  of  a  power  failure. 

Formal  verification  of  system  software  Formally  verifying  the  security  guarantees  of  critical  system 
software  has  become  increasingly  important.  Several  projects  have  demonstrated  the  value  of  formal  verifica¬ 
tion  (e.g.,  [26, 13,  27])  .  The  high-level  goal  of  our  work  is  the  same.  A  model  of  an  adversary  against  forward 
integrity  was  proposed  by  Bellare  et  al.  [9],  which  is  the  same  adversary  model  in  our  formal  verification. 
As  far  as  we  know,  we  are  the  first  to  formally  specify  the  two-phase  adversary  model  and  the  forward 
integrity  property  in  logic.  Another  semi-formal  model  proposed  by  Crossby  et  al.  focuses  on  specifying 
integrity  as  prefix  consistency  of  a  log  and  its  extension  [3] ,  which  essentially  requires  online  commitment  of 
log  entries.  Therefore,  that  model  is  not  relevant  to  our  logging  scenarios.  Ma  et  al.  provide  a  cryptographic 
style  definition  of  the  security  properties  of  a  hash  chain  [28,  29],  much  like  Bellare  et  al.  [9]  However,  unlike 
our  analysis,  they  cannot  verify  security  properties  of  logging  protocols,  as  they  lack  the  logic/language 
framework  to  reason  about  protocols. 

Our  verification  technique  is  based  on  the  compositional  reasoning  principles  developed  by  Garg  et 
al.  [12]  We  additionally  allow  dynamic  forking  of  new  threads  and  resetting  the  machine,  which  are  essential 
in  modeling  and  reasoning  about  the  behavior  of  protocols  across  machine  resets  and  power  failures. 


8  Conclusion 

Our  secure  logging  protocols  use  new  TPM  features  to  guarantee  forward  integrity  of  logs  in  an  offline  setting 
and  address  practical  issues  such  as  limited  disk  space,  high-frequency  log  updates,  and  unexpected  power 
failures.  As  future  work,  we  are  interested  in  investigating  how  to  select  log  block  sizes  for  optimal  balance 
between  the  strength  of  the  security  guarantees  and  performance.  One  promising  direction  is  to  include 
an  adaptive  block  size  choice  module  that  takes  into  consideration  the  costs  of  security  and  performance. 
Another  issue  we  want  to  explore  is  the  scheduling  priority  for  the  logger  process,  so  that  other  processes 
are  not  able  to  exhaust  machine  resources  with  the  aim  of  preventing  logging  and  causing  a  system  crash. 
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Appendix 


We  describe  the  formal  verification  of  Protocol  A  in  detail.  First,  we  present  the  modeling  language  in 
Appendix  A,  then  we  explain  the  program  logic  in  Appendix  B.  Additional  predicates  used  in  the  verification 
are  defined  in  Appendix  C.  The  proof  of  protocol  A’s  tamper-proofness  property  is  presented  in  Appendix  E. 
Finally,  the  encoding  of  the  protocol  is  shown  in  Appendix  F. 


A  Language  and  Model 

Program  syntax.  The  syntactic  constructs  for  expressions,  denoted  e,  are  listed  below. 

Expressions  e  ::=  t  \  act  a  |  let(ei,  a;.e2)  |  if  (5,  61,62)  |  call(/,  t)  |  fork  e,t  \  reset 
Function  dec.  ::=  f{x)  =  e 

An  expression  can  be  a  term  t,  which  includes  the  standard  binary  and  unary  operations  on  constants 
and  variables.  Expression  act  a  denotes  an  atomic  action,  such  as  read  or  write.  The  language  itself  is 
parametrized  over  these  actions,  which  are  instantiated  based  on  the  application  domain.  We  include  memory 
read  and  write  actions  read,  write;  message  send  and  receive  actions  recv,  send;  actions  for  acquiring  read 
and  write  locks  readlock,  writelock;  and  a  polling  action  poll  that  checks  the  value  of  a  memory  location 
and  only  returns  if  a  specific  value  is  stored  in  that  location.  Two  pairs  of  actions  that  are  important  for 
ensuring  tamper-proofness  property  are:  hmac,  verifyhmac  and  seal,  unseal.  The  hmac  action  takes  as  an 
argument,  a  location  I  containing  the  key.  To  successfully  compute  an  HMAC,  I  must  be  readable  by  the 
thread  invoking  hmac.  The  seal  and  unseal  actions  model  corresponding  interfaces  of  TPM  2.0.  For  simplicity, 
we  only  model  sealing  (unsealing)  data  to  the  value  of  a  particular  non-volatile  TPM  counter. 

A  sequencing  expression  is  denoted  let(ei, a;.62),  where  the  return  result  of  the  first  expression  is  used 
in  the  evaluation  of  the  second.  An  expression  can  also  be  an  if  statement  and  a  function  call.  We  allow  a 
program  to  fork  new  threads  (fork  e,t),  where  e  is  the  code  of  the  new  thread  and  t  is  the  principal  that 
the  new  thread  runs  as.  The  expression  reset  resets  (reboots)  the  machine.  The  last  two  constructs  are  our 
extensions  to  Garg  et  al.’s  modeling  language  [12]. 

Finally,  a  program  is  composed  of  a  list  of  function  declarations,  and  an  expression.  The  programs  for 
Protocol  A’s  roles  can  be  straightforwardly  encoded  using  this  language  (presented  in  Appendix  F). 

System  Modeling  Constructs.  The  syntactic  constructs  used  to  model  our  logging  infrastructure  are 
dehned  in  Figure  3.  {V,  :<)  is  an  access  control  lattice,  as  mentioned  in  Section  5. 

Our  model  assumes  distributed  execution.  A  configuration  of  the  system  state,  denoted  C,  is  composed 
of  a  shared  state  C  and  several  threads  Ti , . . . ,  r„  running  in  parallel.  Some  of  the  threads  may  be  controlled 
by  the  adversary.  A  thread  T  is  a  tuple  of  a  unique  thread  ID  /,  an  execution  stack  K,  and  the  expression 
6  currently  being  evaluated.  Note  that  we  use  thread  as  a  technical  term  to  denote  a  run-time  entity  on  the 
machine.  It  is  not  the  threads  used  in  operating  systems.  Since  there  can  be  many  machines  in  the  system, 
we  assume  each  machine  has  a  unique  ID,  denoted  m.  The  thread  ID  /  is  a  tuple  composed  of  the  principal 
X,  with  whose  privilege  the  thread  runs,  a  thread  identifier  unique  to  each  machine  (id),  and  the  machine 
ID  M.  The  execution  stack  AT  is  a  list  of  frames,  denoted  F,  recording  the  evaluation  context.  A  frame  x.e 
denotes  that  this  frame  is  waiting  for  a  return  result  to  be  plugged  into  e. 

Threads  share  several  data  structures,  including  storage  (RAM  and  disk)  cr,  read  and  write  locks  on 
storage  (p,  w),  and  a  network  message  queue  Q.  We  use  I  to  denote  locations  in  the  storage.  To  simplify  our 
presentation,  the  locations  are  hierarchical:  e.g.,  M.disk  refers  to  all  locations  on  the  disk  of  machine  M,  and 
M.disk.sealedloc  refers  to  a  specific  location  on  M’s  disk.  The  read  and  write  locks  represent  access-control 
policies  on  the  machine.  The  read  (write)  lock  map,  denoted  p  (w),  maps  each  storage  location  to  the  thread 
holding  the  lock  of  that  location.  A  location  that  is  mapped  to  the  special  thread  _  is  not  locked. 

Threads  across  different  machines  communicate  to  each  other  via  messages.  The  message  queue  Q  is  a 
buffer  of  in  flight  messages. 

We  assume  there  is  a  permitted  function  deciding  whether  a  thread  is  permitted  to  perform  an  action  in 
a  given  state.  This  function  is  used  to  control  accesses  to  storage  locations  based  on  the  read  and  write  locks 
and  the  access  control  lattice.  It  also  decides  which  messages  a  thread  can  see. 
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x.e 

Stack 

K 

::= 

W\F::K 

Thread 

T 

::= 
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[]\M::Q 

Shared  State 

C 
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a,  p,  uj,  Q 

Configuration 

c 

C  i>  Ti , . . . ,  r„ 

Permissions 

permitted 

:  (Shared  States  x  Thread  Ids 

X  actions)  — >  Boolean 

Fig.  3.  Modeling  constructs 


Reduction  rules.  The  run-time  behavior  of  the  system  is  captured  by  the  reduction  rules,  which  specify 
how  the  system  transitions  from  one  configuration  to  the  next,  one  step  at  a  time.  Selected  reduction  rules 
novel  to  this  work  are  shown  in  Figure  4;  the  rest  of  the  rules  are  same  as  in  Garg  et  al.  [12], 

We  write  l>  T  ^  l>  T'  to  denote  the  one-step  transition  of  a  single  thread,  and  C  — ^  C  to  denote 
the  top-level  reduction  steps  of  the  system,  where  u  is  the  time  when  the  transition  happens.  A  trace  T  is  a 
sequence  of  reduction  steps:  Ci  — A  Ci  •  •  •  C„. 

In  rule  Red-Act,  a  thread  executes  an  atomic  action.  This  rule  is  restricted  by  the  permitted  function, 
which  serves  to  allow/disallow  actions  based  on  the  current  state,  e.g.,  disallow  reads  on  read  locked  memory 
using  the  partial  order  The  system  is  parametrized  over  a  set  of  action  reduction  rules  of  the  form 
C,,I,a  — >  which  evaluates  an  action  a  and  return  the  result  t  and  a  new  state  These  rules  are 

instantiated  based  on  the  application  domain. 

Rule  Red-Conf  allows  arbitrary  interleaving  of  the  reductions  of  individual  threads  in  the  configuration. 
When  a  thread  forks  a  new  thread,  rule  Red-Conf-Fork  picks  a  fresh  id  and  generates  a  new  thread  that 
executes  e  with  an  empty  stack.  Note  that  a  thread  can  only  fork  threads  owned  by  principals  that  are  less 
privileged  than  itself.  The  rule  Red-Conf-Reset  stops  all  threads,  sets  all  volatile  memory  to  null,  clears  all 
locks  and  starts  two  threads  owned  by  principals  root  (the  OS)  and  tpm. 

B  Logic  of  Programs 

We  extend  the  program  logic  by  Garg  et  al.  [12]  to  accommodate  the  new  language  constructs.  Similar 
to  prior  work,  the  program  logic  aims  to  derive  security  properties  of  a  system  composed  of  both  trusted 
components,  which  runs  the  prescribed  protocol;  and  adversarial  components,  which  runs  arbitrary  code, 
but  confined  to  its  capabilities  as  specified  in  the  adversary  model. 

Property  specifications.  Security  properties  are  specified  as  first-order  logic  formulas  (shown  below) .  Most 
constructs  are  standard.  We  write  p  @  u  to  mean  that  predicate  p  is  true  at  time  u.  Similarly,  ip  @  u  means 
that  formula  p  holds  at  time  u.  We  write  (p  on  I)  to  denote  that  p  is  true  during  the  time  interval  I.  Using 
these  explicit  time  points,  we  can  concisely  specify  event-orderings  on  the  trace,  which  is  essential  for  the 
formal  specification  of  the  tamper-proofness  property. 

Formulas  p,  4’  ■■=  p  @  u  \  b  \  t  =  t'  \  ui  <  U2  |  T  |  T 

I  p@u\pA'ip\p\/tp  \  —^p  I  't/x.p  I  3x.p 
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C  >  T  C'  >  r' 


permitted{C,I,a)  (^,I,a  ^  ,I,t 
C  l>  /  ;  x.e  ■.■.  K  ;  act  a  ('  l>  I ;  K  ;  e\t/x\ 


c  >  Ti  c'  >  7^' 

c  >  Ti  I  . . .  I  Ti  I  . . .  I  r„  ^  c'  >  Ti  I  . . .  I  T/  I  . . .  I  T„ 


Red-Conf 


m  =  machine(I)  id  fresh  X  ^  owner{I) 

C  >  Ti  I  ...  I  / ;  (x.e)  v.  K  \  fork  e  ,X  \  ...  |  T„  — >• 
C>  Til  ...  \  I-K-e{J/x}  \  ...  |T„|(X,id,m);.;e' 


Red-Conf-Fork 


I  £  u}{m.ram.sh)  l' .id'  fresh 

I  .id  fresh  a  =  a[{locs{m)  —  locs{m,  {disk,  tpm.nv})  i— >■  nul!]{p  ,uj  )  =  {p,  uj)[locs{m)  i— >■  _] 
/'  =  [root, id', m)  and  l"  =  [tpm,id" ,m)  m  =  machine{I) 

C  >  Ti  I  ...  \I  ■,K  ■,  reset  |  . . .  |  r„  — >•  l>  (^i  |  ...  \T„)\ Threads{m)  |  ;  eos  |  f  ;  etpm 


Red-Conf- Reset 


Fig.  4.  Selected  reduction  rules 


r  h  [e]{ub,Ue,i,x)(p 
r  h  {e}(Wf,,  Me,  i)^ 


r\-  p 


Given  a  trace  that  contains  the  complete  evaluation  of  e  between  time  Ub  and  Ue, 
by  thread  /  and  returns  t,  ip\Ub,  Ue,  I,  t/ub.  Me,  i,  x]  holds  on  that  trace. 

This  trace  is  allowed  to  contain  other  executing  threads,  including  malicious  ones. 
Given  a  trace  that  contains  an  incomplete  evaluation  of  e  between  time  Ub  and  Ue 
by  thread  I,  ip[Ub,Ue,  I /ub,Ue,i]  holds  on  the  trace. 

Similarly,  this  trace  may  contain  attacker  threads. 
ip  holds  on  any  trace  that  satisfies  F 


Fig.  5.  Summary  of  judgments 


Reasoning  principals.  The  program  logic  consists  of  three  main  judgments,  summarized  in  Figure  5.  For 
clarity  of  presentation,  we  omit  several  contexts  from  the  judgments  as  they  mostly  remain  unchanged. 
Context  r  contains  formulas  that  are  assumed  true.  The  first  judgment  asserts  partial  correctness  properties 
of  an  expression;  the  second  asserts  invariant  properties  of  an  expression;  and  the  last  judgment  is  the 
standard  first-order  logic  judgment. 

To  give  a  flavor  of  the  rules  in  our  program  logic,  we  show  one  rule  for  deriving  the  effects  of  completing 
a  fork  action  and  one  rule  deriving  properties  of  systems  containing  a  trusted  component. 


L  ~<  owner(i)  J  fresh 

- = - -  P 

r  h  [fork  e,  L]{ub,  Me,  i,  x)[x  =  J)  A  Start(J,  e)@Me  A  Owner(J,  L)  @  Me 

r  h  {e}(Mf,,  Me,  i)(p{ub.  Me,  i)  F  h  StartffX,  id,  M),  e)  <§)  m 

- ; - , - ; - , — ^ - Honth 

F  h  Vm  .  (m  >  m)  a  ^Reset(M)  on  (m,  m  ]  D  p>[u,  u  ,  [X,  id,  M)) 


Rule  PK  states  that  fork  e,  L  is  only  allowed  if  the  new  thread  runs  as  a  principal  that  has  fewer  privileges 
than  its  parent  thread;  that  the  return  value  is  the  newly  generated  thread  ID  J;  and  that  the  new  thread 
J  starts  to  execute  e  when  fork  finishes.  Rule  Month  is  the  key  rule  transitioning  from  reasoning  about  the 
program  of  trusted  components  to  deriving  a  property  of  the  trace.  This  is  similar  to  the  rule  of  the  same 
name  in  [12].  Essentially,  if  a  thread  /  starts  e  at  time  u,  and  we  know  that  e  has  an  invariant  tp  (at  any 
time  point  before  e  hnishes,  ip  is  true),  then  at  any  later  time  point  u'  and  the  machine  has  not  been  reset  in 
between,  then  the  invariant  guaranteed  by  e  holds  between  these  two  time  points.  For  instance,  if  the  thread 
invariant  states  that  this  thread  never  reads  location  M.disk.sealedloc,  then  that  invariant  holds  from  the 
start  of  the  thread  till  the  next  reset. 
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C  Additional  predicates 


Predicate  MayDerive(ei,  62,  S)  means  that  62  can  be  derived  from  ei  given  the  set  of  terms  S.  We  show  the 
new  rules  below  and  other  rules  are  the  same  as  those  in  [13].  The  first  rule  states  that  from  a  term  e,  its 
hash  can  always  be  computed.  The  last  two  rules  state  that  data  sealed  within  a  blob  can  be  extracted  if 
either  the  TPM  counter’s  value  is  the  same  as  the  value  that  blob  is  sealed  to,  or  the  TPM’s  key  is  known. 


tpm. counter  =  n  tpm.key  G  S 

Mayderive(e,  hash{e),  S)  Mayden\/e{SEALtpm.key{t,  n),t,  S)  Mayder\\/e{SEALtpm.key{t,  n),  t,  S) 

The  predicate  Has(f,  s)@u  is  defined  as  there  exists  m  such  that  (1)  m  contains  s  given  S,  (2)  i  has  S,  and 
(3)  the  thread  i  has  either  received  m,  or  read  m  from  the  storage,  or  computed  m  using  the  hmac  action. 

Has(f,  s)  @  u  =  3u',  u" .  [u"  <  u'  <  u)  A 

3m.  (^{31  Recv(z,  j,  m)  @  u”  V  Read(z,  ?,m)  @  u"  V  Hmac(z,  to',  m)  @  m")  A 

(35”.  HasSet(z,  S)  @  u'  A  Contains(TO,  s,  S)  @  u')^  A 
^  Reset  0  on  [u",  u] 

HasSet(z,  S)  @  u  =  Vs.(s  €  S)  D  Has(z,  s)  @  u 

The  predicate  Has  satisfies  the  following  properties.  These  are  derivable  from  the  definition  of  Has. 

Vz,  s,  u,  u' .  Has(z,  s)  @  u  A  (u'  >  u)  A  ^Reset()  on  [zz,  zz'j  D  Has(z,  s)  @  v!  (HI) 

Vz,  s,  u,  u' .  Has(z,  s)  @  u  A  {u'  <  u)  A  ^Has(z,  s)  on  [u' ,  u)  D 

3to.(  (3/,j,  to'.  Recv(z,  j,  to)  @uV  Read{i,l,m)  @  zz  V  Hmac(z,  to', /,  to)  @  u) 

A  {3S.  HasSet(z,  S)  @  u  A  Contains(TO,  s,  S)  @  zz))  iH2) 

HI  states  that  a  thread  retains  information  s,  unless  there  is  a  reset.  H2  states  that  the  time  zz  when 
Has  becomes  true  for  thread  z  is  the  time  when  thread  z  obtains  to  that  enables  the  derivation  of  s. 

We  expand  the  definition  of  NoAdv(zz)  from  Section  5.  Locations  LoggerLoc(L)  are  instantiated  with  the 
locations  M.ram.keyloc,  M.tpm.v. channel,  M.ram.logger  J.pm,  M.ram.logger_sh  and  LoggerOSLoc(i)  with 
M  .ram.logger  -OS . 


yi,vi, . . . ,  Vi2,  zz.  Owner(i,  root)  @  zz  D  ^RW(z,  M.ram.keyloc,  vi,V2)  @  u  A  ^RW(z,  m.tpm.v .channel ,  V3,  V4)  @  zz  A 
^RW(z,  m.tpm.v. channel,  V5,  vq)  @  u  A  ^RW(z,  M.ram.loggerJpm,  vy,  vs)  @  zz  A 
^RW(z,  M.ram.loggersh,  vg,  zzio)  @  zz  A 
{RNy{i,  M.ram.logger-os, Vii,Vi2)  @uD  HT  (i,  root,  OS)) 

Finally,  we  define  predicates  used  in  the  main  theorem  and  the  key  invariant  properties  (Section  5). 

RW(z,  I,  z)i,  W2)  @  zz  =  Read(z,  I,  m)  @  zz  V  Write(z,  I,  vg) 

inMem(z,  m)  @  u  =  31.  Mem(?,  to)  @  zz  A  CanRead(z,  1)  @  u 

LaStLogldx(fc,  zz,  ZZend)  =  (fc  >  0)  A  (zz  <  Uend)  A 

Vzz',  i,j,  V,  v',  z.  HT(z,  L,  LOGGER)  @  zz  A  (zz  <  zz'  <  Uend)  A  {k  >  1)  A  {z  >  k)  A  \Nhte{i,fileLoc{k),v)  @  zz  A 
HT(j,  L,  LOGGER)  @  zz'  D  -^\Nhte{j,  fileLoc{z),v')  @  zz' 

keyOwnerln(zz)  =  Vzz',  to,  n,  i,  S.  (zz'  >  zz)  A  Has(z,  to)  @  zz  A  Contains(TO,  key{n),S)  @  zz'  A  -^{tpm.key  €  S) 

D  HT  {i,,L,  LOGGER)  @  zz  V  Owner(z,  tpm)  @  zz  V  Owner(z,  V)  @  u 

keyMemln(zz)  =  Vzz',  n,  I,  to,  S.  (zz'  >  zz)  A  Mem(?,  to)  @  zz  A  Contains(TO,  key{n).  S')  @  zz'  A  -^{tpm.key  €  S) 

D  I  G  {M.disk.sealedkey,  M.ram.keyloc,  M.tpm.v. channel} 
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oldKeyAdv(u,  Ua)  =  Vi,  m,  v,  S,  ka,  ui.  {v  >  u  >  Ua)  A  Has(i,  m)  @  u  A  tpm.key  ^  S'  A 

Contains(m,  key{ka),  S)  @  v  A  ^HT(i,  L,  LOGGER)  @  u  A 
^Owner(i,  ipm)  @u  A  LastLogldx(A:,  uj,  Uo)  A  {ka  >  1) 

D  ka  >  k  +  1 

oldKeyNotlnMem(u,  Ua)  =  Vi,  ui,k,  k' ,  S,  m.  {u  >  Ua)  A  (fc  >  1)  A  LastLogldx(A:,  ui,  Ua)  A 

A  {1  <k'  <k)  A  {I  &  M)  A  Mem(/,  m)  @  u  A  tpm.key  ^  S 
D  ^Contains)™,  key{k'),  S)  @  u 


D  Axioms 

We  assume  the  following  axioms,  which  have  been  proven  sound  based  on  the  semantic  model. 


Axl 

Ax2 

Ax3 

AxA 

Axb 

Ax& 

Axlrd 

AxTwr 

AxS 

Ax9 

AxlO 

Axil 

Axl2 

Axl3 

AxlA 


V/,  m,  u,  V.  Mem(i,  m)  @  u  A  {v  <  u)  A  ^Mem(i,  m)  @  v  D 
3u',  i.  {v  <  u'  <  u)  A  Write(i,  I,  m)  @  u' 

Vi,  I,  m,  v! .  Write(i,  i,  m)  @  u'  D  3u".(u"  <  u')  A  Has(i,  m)  @  u"  A  ^Reset()  on  [u" ,  u'] 

Recv(i,  j,TO)  @  u'  D  3u".{u"  <  u')  A  Send(j,i,TO)  @  u” 

yi,j,m,u'.  Send(i,  j,  to)  @  u'  D  3u".{u"  <  u')  A  Has(i,TO)  @  u"  A  ^Reset()  on  {u" ,u'] 

Vi,i,TO,  u'.  Read(i,i,TO)  @  u'  D  3u'' .{u"  <  u')  A  Mem(i,TO)  on  [u" ,u']  A  ^Reset()  on  {u" ,u'] 

Vi,  i',  u,  u',  I,  V.  Poll(i,  l,v)  @  u  A  CanWrite({i,  i'},  1)  @  u  A  ^Mem(/,  v)  @  u'  A  {u'  <  u)  A 
^Reset()  on  {u' ,  u]  A  ^Write(i,  I,  f)  on  (u',  m]  D  Write(i',  l,v)  @  u 
Vi,  j,  u,  u',  I,  I,  J.  lsReadLocked(i,  1)  @  u  A  Owner(i,  I)  A  I  A  J  A  Owner(j,  J)  D  CanRead(j,  1)  @  u 

yi,j,  u,  u',  I,  I,  J.  lsWriteLocked(i,  1)  @  u  A  Owner(i,  I)  A  I  A  J  A  Owner(j,  J)  D  CanWrite(j,  1)  @  u 

Vi,  I,  TO,  u.  Read(i,  l,m)  @  u  D  Mem(i,  m)  @  u 

Vi,  mac,  d,  key,  u.  VerifyHmac(i,  mac,  d,  key)  @  u  D  3j,  I,  u' .{u'  <  u)  A  Hmac(j,  d,  I,  key)  @  v! 

Vi,  mac,  d,  key,  u.  Hmac(i,  d,  I,  key)  @  uD  CanRead(i,  1)  @  u  A  Mem(i,  key)  @  u 
Vi,  K,  u" ,  u.  Owner(i,  K)  @  u"  A  ^Reset()  on  {u” ,  u]  D  Owner(i,  K)  @  u 
yi,K,u" ,u.  HT(i,P,  iV)  @  u"  A  ^Reset()  on  {u",u]  D  HT(i,  P,  iV)  @  u 
Vi,  K,  u”,  u.  ^Owner(i,  K)  @  u"  A  ^Reset()  on  {u" ,  u]  D  ^Owner(i,  K)  @  u 
Vi,  K,  u" ,  u.  ^HT (i,  P,  K)  @  u"  A  ^Reset()  on  {u" ,  m]  D  ^HT (i,  P,K)  @  u 


E  Proofs 

We  present  the  proofs  of  the  following  four  properties. 

1.  Vm.m  <  Ua  D  keyOwnerln('u)  3.  Vm.u  >  Uo  3  oldKeyAdv)^,  Uo) 

2.  Vm.m  <  Ua  D  keyMemln(M)  4.  Vm.u  >  Ua  3  oldKeyNotlnMem('u,  Uo) 


E.l  Proofs  of  1  and  2 

The  proof  proceeds  by  transfinite  induction  on  u.  First,  we  show  that  keyOwnerln(— oo)  A  keyMemln(— oo). 
Clearly,  Vi,i.  ^Has(i,t)  @  — oo  since  Has  relies  on  actions  in  the  past  and  no  action  has  happened  at  — oo. 
Thus,  keyOwnerln(— oo)  trivially  holds.  Also,  we  assume  that  keyMemln(— oo)  holds,  which  is  justified  by  the 
fact  that  the  system  administrator  hands  over  the  machine  with  the  key  at  location  M.disk.sealedkey. 

For  the  induction  hypothesis,  assume  that  keyOwnerln(M)  A  keyMemln)^)  for  all  u  <  ug  <  Ua  for  some 
uq.  We  need  to  show  keyOwnerln(uo)  A  keyMemln('Uo). 


Proving  keyMemln(Mo)  holds:  We  do  so  by  contradiction.  First,  assume  7  I - ^keyMemln(uo).  This  can 

be  expanded  to  be  written  as  (with  L  standing  for  {M.disk.sealedkey,  M.ram.keyloc,  M .tpm.v .channel}) 

Ip  =  3u  ,  n,  I,  TO,  S.{u  >  Uq)  a  Mem(l,  to)  @  uq  A  Contains)??!,  key{n),  S)  @  u  A  -^{tpm.key  G  S)  A  I  ^  L 
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Choose  fresh  values  of  the  existential  (captured  in  the  same  formula  used  on  the  left  as  'ijj)  to  get 

7,  h  (mq  >  uo)  A  Mem(l,TO)  @  uo  A  Contains(mo,  key{no),So)  @  Uq  A  -^{tpm.key  G  Sq)  A  Iq  ^  L  (A1) 

Using  Axion  Axl  and  Ax2  it  is  easy  to  prove  that 

Wl,  m,  u,  V.  Mem(l,  m)  @  u  A  {v  <  u)  A  ^Mem(?,  m)  @  v  D 

3u",u',i.(u"  <  u'  <  u)  A  Write(i,?,m)  @  u'  A  Has(t,m)  @  u"  A  ^Reset()  on 

In  particular,  if  we  choose  I  =  lo,m  =  mo,  u  =  ug,  v  =  — oo,  we  get 

7,^/;  h  Mem(^o,  m-o)  @  uq  A  ^Mem(/o,mo)  @  — oo  D 

3u'' ,u' <  u'  <  Uq)  a  \Nr\te{i,lo,mo)  @  u'  A  Has(i,TOo)  @  u”  A  ^Reset()  on  {u'',u']  (i?l) 

The  contrapositive  within  keyMemln(— oo)  yields 

keyMemln(— oo)  =  Vn,  I,  m,  S,u' .  I  ^  L  D  ^(Mem(l,  m)  @  — oo  A  Contains(m,  key{n),  S)  @  u'  A  ^{tpm.key  G  S)) 
In  particular,  if  we  choose  I  =  lo,m  =  mg,  n  =  ng,S  =  Sg,u'  =  Wq,  we  get 

'y,'tp  \-  Ig  ^  L  G)  ^(Mem(lo,  mg)  @  — oo  A  Contains(mo,  key{ng),  Sg)  @  Uq  A  ^{tpm.key  G  Sg)) 

Moving  clauses  to  other  side  of  implication  we  get 

7,  V'  1“  ^0  ^  A  A  Contains(mo,  keying),  Sg)  @  Ug  A  -^{tpm.key  G  Sg)  D  ^Mem(lo,  wg)  @  — oo 
Now,  using  (i?l)  we  get 

7,'i/)  h  Mem(/g,  mg)  @  ug  A  Ig  ^  L  A  Contains(mo,  key(ng),  Sg)  @  Ug  A  -^{tpm.key  G  Sg)  D 

3u'' ,u' <  u'  <  ug)  A  Wnte(i,  lg,mg)  A  Has(i,mg)  @  u"  A  ^Reset()  on  {u" ,u']  (i?3) 

Combining  i?3  with  A1  and  using  modus  ponens  we  get 

7,1/^  h  3u',u'',i.  {u"  <  u'  <  Ug)  A  Has(i,mg)  @  u”  A  ^Reset()  on  {u'',u']  A  Write(i, /g,  mg)  @  u' 

A  (ug  >  Ug)  A  Contains(mg,  key{ng),  Sg)  @  Ug  A  Ig  ^  L  A  ^{tpm.key  G  Sg) 

Again  using  fresh  values  for  the  existential  we  get 

7,^/’  h  {u'!_i  <  u'_i  <  Ug  <  Uq)  a  Has(ig,mg)  @  u'_!_i  A  ^Reset()  on  {u'!_-^,u'_-^  A 

Write(io,  Ig,  mg)  @  m'_i  A  Contains(mg,  key(no),  Sg)  @  Uq  A  Ig  ^  L  A  ^(tpm.key  G  Sg) 

Since,  u'^i  <  ug  we  have  from  induction  hypothesis  that  keyOwnerln(t6"  j^)  holds.  From  the  definition  of 
keyOwnerln)^"  ]^)  and  the  just  proved 

Has(tg,mg)  @  u'!_i  A  Contains(mg,  fce7/(ng),  S'g)  @  Ug  A  -^{tpm.key  G  Sg) 


we  can  conclude  that 

HT(t,  L,  LOGGER)  @  u'^i  V  Owner(z,tpm)  @  u'!_i 


Thus, 

7,1/^  h  {u'-i  <uo<  Ug)  A  (HT(ig,L,  LOGGER)  @  u'^i  V  Owner(ig,  tpm)  @  m"i)  A 

^Reset()  on  {u'!_i,u'_-^\  A  Write(zg,  ?g,  mg)  @  m'_i  A  Contains(mg,  fcey(ng),  ^)  @  Ug 
A  Ig  ^  L  A  -^{tpm.key  G  Sg) 

Using  Axil  and  Axl2  with  ^Reset()  on  {u'!_i,u'_i],  we  get  HT(ig, i, LOGGER)  @  u'_i  V  Owner(zg,  tpm)  @ 
u'_i.  Thus,  we  get 


7, '0  h  {u'-i  <  Ug  <  Ug)  A  (HT(tg,  L,  LOGGER)  @  u'_i  V  Owner(io,  tpm)  @  u'_i)  A 

Write(tg,  Ig,  mg)  @  u'_i  A  Contains(mg,  A:ej/(ng),  0)  @  Uq  A  Ig  ^  L  A  -^{tpm.key  G  Sg)  {R2) 


19 


It  is  possible  to  prove  by  analyzing  the  programs  that 

7,  f/'  b  Vn,  l,m,u,  i,  v,  S.  {u  <  Uq)  A  (u  <  v)  A  HT (i,  L,  LOGGER)  @  m  A 

Write(i,  l,m)  @  u  A  Contains(TO,  key{n),S)  @  v  A  -^{tpm.key  G  S)  D  I  G  L 
7,  f/'  b  Vn,  I,  m,  u,  i,  v,  S.  (u  <  ug)  A  (u  <  v)  A  Owner(i,  tpm)  @  u  A  Write(i,  l,m)  @u  A 
Contains(m,  key(n),  S)  @  v  A  -^(tpm.key  G  S)  D  I  =  m. tpm. v. channel 

The  above  proofs  rely  on  the  induction  hypothesis  about  keyOwnerIn  and  keyMemln  to  claim  that  the  log 
entries  themselves  do  not  contain  any  key.  Instantiate  the  universal  to  specific  values  and  combine  the  above 
two  results  as  follows 

7,'i/'  b  {u'_i  <uo<  Uq)  a  (HT(io,T,  logger)  @  u'_i  V  Owner(Io,  tpm)  @  u'_i)  A 

Write(io,  Ig,  uio)  @  u'_i  A  Contains(mo,  key{ng),Sg)  @  u'g  A  -^{tpm.key  G  Sg)  D  Ig  G  L 

Thus,  using  (i?2)  and  the  above  result,  we  can  prove  the  following,  which  is  a  contradiction. 

'y  ^  Ip  Ig  G  L  A  Ig  ^  L 


Proving  keyOwnerln(tto)  holds:  We  do  so  by  contradiction. 

Assume  7  I - ^keyOwnerln(uo).  In  an  expanded  form  this  is  same  as 

3uP  m,  n,  i,  S.  {u'  >  ug)  A  Has(i,  m)  @  ug  A  Contains(m,  key{n),  S)  @  u'  A 

-^(tpm.key  G  S)  A  ^HT(i,  L,  LOGGER)  @  uq  A  ^Owner(i,  tpm)  @  ug  A  ^Owner(t,y)  @  ug 

Let  the  above  formula  be  ip.  Again  fix  values  of  existential  so  that 

7,  V'  b  (ug  >  Ug)  A  Has(zo,  mg)  @  ug  A  Contains(mo,  key(ng),  Sg)  @  Ug  A 

-^{tpm.key  G  Sg)  A  ^HT(zo,  T,  LOGGER)  @  ug  A  ^Owner(zo,  tpm)  @  Mq  A  ^Owner(zo,  F)  @  Ug  {A2) 


Now,  we  know  that  Has(zo,  mg)  D  ^Reset()  @  u.  Also,  using  Axl3  and  AxlA  and  picking  Up  to  be  the  max  of 
the  witnesses  for  the  existential  u'  for  the  tpm  thread  and  the  logger  thread,  with  the  verifier  never  reseting, 
we  get  Vzz.  {up  <  u  <  ug)  D  ^HT(zo,  T,  LOGGER)  @  u  A  ^Owner(zo,  tpm)  @  zz  A  ^Owner(zo,  I^)  @  u.  Using 
facts  from  A2  we  get 

Vu.  {up  <u  <  Ug)  D  ^HT(zo,  A,  logger)  @u  A 

^Owner(zo,  tpm)  @  u  A  ^Owner(zo,  V)  @  u  A  Contains(mo,  keying),  Sg)  @  zzg  A  ^{tpm.key  G  Sg)  (i?l) 

Taking  contrapositive  within  keyOwnerln(zz)  we  get 

keyOwnerln(zz)  =  Vzz',  m,  n,  i,  S.  ^HT(z,  L,  LOGGER)  @  u  A  ^Owner(z,  tpm)  @  u  A  ^Owner(z,  V)  @  uD 
^^(zz'  >u)  A  Has(z,  m)  @  u  A  Contains(m,  key{n),  S)  @  u'  A  -^{tpm.key  G  S)^ 

Instantiating,  with  u  <  ug,  and  noting  that  u  <  ug  <  u'g  we  get 

7  b  Vzz.  (zz  <  Ug)  A  ^HT(zo,  A,  LOGGER)  @  u  A  ^Owner(zo,  tpm)  @  u  A  ^Owner(zo,  V)  @  uD 
^fHas(zo,mo)  @u  A  Contains(mo,  fcep(no),  5'o)  @  zzq  A  ^{tpm.key  G  Sg)\ 


or  rearranging 

7  b  Vzz.  ^HT (zg,  A,  LOGGER)  @  u  A  ^{tpm.key  G  Sg)  A  ^Owner(zg,  tpm)  @  u  A  ^Owner(zg,  V)  @  u  A 
Contains(mo,  key{ng),  Sg)  @  u'g  D  ^(zz  <  ug)  V  ^Has(zo,  mg)  @  u 

Using  this  with  (Bl)  we  get 

7  b  Vzz.  (zZp  <  zz  <  Ug)  D  —•{u  <  Ug)  V  ^Has(zg,  mg)  @  ZZ 
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which  is  same  as  Vi6.  {up  <  u  <  uq)  D  ^Has(io,  mo)  @  u  and  which  is  same  as  ^Has(io,  mo)  on  [up,  uq).  Thus, 
we  have 

7,V’  h  ^Has(zo,mo)  on  [up,uo) 


We  know  from  A2  that 


7,z/>  h  Has(zo,mo)  @  uq 


Now,  invoking  property  H2  about  Has  we  get 


7,  z/i  h  3m.  (  {31,  j,  m' .  Recv(io,  j,  m)  @  uo  V  Read(io,  I,  m)  @  mo  V  Hmac(io,  m',  I,  m)  @  uq) 
A  (35'.  HasSet(io,  S)  @  uq  A  Contains(m,  mo,  5)  @  uq)) 


Instantiating  the  existential  with  fresh  values  we  get  (with  the  formula  captures  in  'ip) 


7,  f/'  b  (Recv(zo,  jo,  m_i)  @  mo  V  Read(zo,  Iq,  m_i)  @  uo  V  Hmac(io,  mg,  Iq,  m_i)  @  uo) 
A  HasSet(zo,  5_i)  @  Uq  A  Contains(m_i,  mo,  5_i)  @  Uq  A  ^{tpm.key  G  Sq) 


From  A2  we  know  that 

7,  b  (uq  >  Uq)  a  Contains(mo,  A:ey(no),  5o)  @  Uq  A  ^HT(zo,  L,  LOGGER)  @  mo  A 
^Owner(zo,  fpm)  @  mo  A  ^{tpm.key  G  5o)  A  ^Owner(zo,F)  @  uo 


First,  note  that  Contains(m_i,  mo,  5_i)  @  mo  A  {uq  >  uq)  A  Contains(mo,  fcey(no),  5o)  @  Uq  implies  that 
Contains(m_i,  fce2/(no),  5oU5_i)  @  Ug  A  (ug  >  Ug).  Also,  we  know  that  ^Owner(zg,  tpm)  A  HasSet(zo,  5_i)  D 
-^{tpm.key  G  5_i)  Thus,  we  can  infer  that 

7,  b  (ug  >  Uo)  A  Contains(m_i,  key(no),  So  U  5_i)  @  u'o  A  ^{tpm.key  G  5g  U  5_i)  A 
^HT (zg,  L,  LOGGER)  @  uo  A  ^Owner(zg,  tpm)  @  zzg  A  ^Owner(zo,  F)  @  zzg  A 
(Recv(zg,  jo,m_i)  @  zzg  V  Read(zg, /g,  m_i)  @  zzg  V  Hmac(zo,  mg, /g,  m_i)  @  uo) 

We  analyze  the  three  disjuncts  separately  reaching  contradictions  in  each  case.  We  skip  the  Hmac  case, 
since  it  is  similar  to  Read.  Thus,  we  analyze  two  sub  cases  below. 


SubCase  1:  Recv(zo,  jo,  m_i)  @  zzg 
This  case  yields 

7,  zj  b  (zZq  >  Uq)  a  Contains(m_i,  key{no),  5g  U  5_i)  @  zZg  A  ^{tpm.key  G  5o  U  5_i)  A 

^HT(zo,T,  LOGGER)  @  Uo  A  ^Owner(zo,  tpm)  @  uo  A  ^Owner(zo,  V)  @  uo  A  Recv(zo,  jg,  m_i)  @  uq 

Using  Axi  and  Ax4  we  can  conclude  that 

7,  zj  b  (zzg  >  Uo  >  zz_i  >  zz_2)  A  Contains(m_i,  key{no),  5g  U  5_i)  @  zZg  A  -^{tpm.key  G  5o  U  5_i)  A 

^HT (zg,  L,  LOGGER)  @  zzg  A  ^Owner(zo,  tpm)  @  uq  A  ^Owner(zo,  V)  @  uq  A  Send(jo,  zg,  m_i)  @  zz_i 
A  Has(jo,m_i)  @  zz_2  A  ^Reset()  on  (zz_2,zz_i] 

Now,  we  can  invoke  keyOwnerln(zz_2)  as  zz_2  <  zzg  <  zZg  with  suitable  instantiation  to  get 

7,  zj  h  (zzg  >  zzg  >  zz_i  >  U-2)  A  (HT(jo,  L,  LOGGER)  @  zz_2  V  Owner(jg,  tpm)  @  zz_2  V  Owner(jo,  V)  @  U-2)  A 
^HT(zo,  L,  LOGGER)  @  uq  A  ^Owner(zo,  tpm)  @  uo  A  ^Owner(zo,  U)  @  ^o  A  Send(jo,  zo,  m_i)  @  zz_i  A 
Contains(m_i,  fcez/(rzo),  5o  U  5_i)  @  Ug  A  ^Reset()  on  (zz_2,  zz_i]  (i?2) 

It  is  possible  to  show  by  analyzing  the  programs  that 

7,  zj  h  Vzz,  m,  u,  i,j,  V,  S.  {u-2  <  u  <  ug)  A  {u  <  v)  A  HT (z,  L,  LOGGER)  @  zz_2  A 
^Reset()  on  (zz_2,zz-i]  A  Contains(m,  A:ep(rz),  5)  @  v  D  ^Send(z,  j,  m)  @  u 
7,  z/j  h  Vzz,  m,  zz,  z,  j,  V,  S.  (zz_2  <  u  <  Ug)  A  {u  <  v)  A  Owner(z,  tpm)  @  zz_2  A 
^Reset()  on  (zz_2,zz-i]  A  Contains(m,  A:ep(rz),  5)  @  v  D  ^Send(z,  j,  m)  @  u 
7,  zj  F  Vzz,  m,  zz,  z,  j,  v,  S.  (zz_2  <  u  <  ug)  A  {u  <  v)  A  Owner(z,  V)  @  U-2  A 

^Reset()  on  (zz_2,  zz_i]  A  Contains(m,  key{n),S)  @  v  D  ^Send(z,  j,  m)  @  u 
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Instantiating,  and  combining  we  get 

7,  ■(/>  h  {u-2  <  u-i  <  uo  <  Uq)  a  (HT(jo,i,  logger)  @  u-2  V  Owner(jo,  tpm)  @  M-2  V  Owner(jo,IA)  @  U-2)  A 
^Reset()  on  (u-2,  U-i]  A  Contains(m_i,  fce?/(no),  5'o  U  S-i)  @  Uq  D  ^Send(jo,  *0)  w_i)  @  U-i 

Thus,  using  the  above  result  with  {B2)  we  get 


7,'i/'  I-  ^Send(jo,*o,TO_i)  @  u_i 

but,  we  also  know  from  B2  that  7,  V"  Send(jo,  zq,  m_i)  @  U-i,  which  is  a  contradiction. 

Next,  we  analyze  the  second  disjunct 

SubCase  2:  Read(zo,  ?0;  w_i)  @  uq 
This  case  yields 

7,'i/'  1“  (wg  >  Uq)  a  Contains(m_i,  A:ej/(no),  5'o  U  S-i)  @  Mq  A  HT(zo,  L,  LOGGER)  @  ug  A 
^^Owner(ig,  tpm)  @  ug  A  ^Owner(zg,  F)  @  ug  A 
{tpm.key  ^  S'g  U  S'-!)  A  Read(zg,  /g,  m_i)  @  Ug 

Now,  using  Ax?)  we  can  conclude  that 

7,  V'  1“  (wg  >  Uq  >  u")  A  Contains(m_i,  A:ej/(ng),  Sg  U  S'-!)  @  Ug  A  HT(zg,  L,  LOGGER)  @  ug  A 
^Owner(zo,  tpm)  @  ug  A  ^Owner(ig,  y)  @  ug  A  {tpm.key  ^  SgU  S-i)  A 
Read(zg, /g, m_i)  @  ug  A  Mem(/g, m_i)  on  [u'\ug]  A  ^Reset()  on  [u" ,ug] 

Now  using  induction  hypothesis  for  predicate  keyMemln('u"),  given  u"  <  ug,  we  get 

7,'i/'  1“  {ug  >ug>  u")  A  Contains(TO_i,  fcey(ng),  S'g  U  S-i)  @  Ug  A  HT(zg,  L,  LOGGER)  @  ug  A 
^Owner(zg,  tpm)  @  Ug  A  ^Owner(zg,  y)  @  zzg  A  {tpm.key  ^  SgU  S-i)  A 
Read(zg,  Ig,  TO_i)  @  zzg  A  Mem(lg,  TO_i)  on  [u'',ug]  A  {Ig  G  L)  A  ^Reset()  on  [u'',ug]  (Cl) 

For  now,  assume  a  formula  ^  will  be  proved  later)  given  by 

7  h  Vu,  u” ,  z,  zz,  TO,  S',  z;,  1.  -HT(z,  L,  LOGGER)  @  u  A  ^Owner(z,  tpm)  @  u  A  ^Owner(z,  y)  @  zz 
A  Mem(?,  to)  on  [zz",  zz]  A  (w  >  zz)  A  (zz"  <  zz  <  zzg)  A  I  G  L  A  ^Reset()  on  [zz",  zz]  A 
{tpm.key  ^  S)  D  ^Read(z,  /,  to)  @  zz  V  ^Contains(TO,  key{n),S)  @  v 

^  basically  states  that  any  thread  that  is  not  the  logger,  tpm  or  verifier  does  not  read  I  G  L  or  that  memory 
location  I  does  not  contain  any  key.  ^  can  be  rearranged  as 

7  h  Vzz,  zz",  i,  n,  TO,  S,  V,  1.  -HT(z,  L,  LOGGER)  @  zz  A  ^Owner(z,  tpm)  @  u  A  ^Owner(z,  y)  @  zz  A 
Mem(Z,TO)  on  [zz",zz]  A  {v  >  u)  A  (zz"  <  zz  <  zzg)  A  ^Reset()  on  [zz",zz]  A  {tpm.key  ^  S)  A 
Read(z,  l,m)  @  u  A  Contains(TO,  key{n),  S)  @  v  D  I  ^  L 

Then,  instantiating  with  proper  values  (e.g.,  zz  =  zzg)  we  get 

7  I - ^HT(zg,  L,  LOGGER)  @  zzg  A  ^Owner(z,  tpru)  @  zzg  A  ^Owner(z,  y)  @  zzg  A  (zzg  >  zzg)  A  (zz"  <  zzg)  A 

Mem(/g,  TO_i)  on  [zz",zz]  A  ^Reset()  on  [zz",zzg]  A  {tpm.key  ^  Sg  U  S_i)  A 
Read(zg,  Ig,  to_i)  @  ug  A  Contains(TO_i,  A:ez/(rzg),  Sg  U  S_i)  @  Ug  G)  Ig  ^  L 

Thus,  using  with  (Cl)  we  obtain  the  contradiction 

7^  z/?  b  ^g  G  T  A  ^g  ^  T 


Thus,  we  now  focus  on  proving  ^ 

7  h  Vzz,  zz",  z,  n,  TO,  S,  z;,  1.  -HT(z,  L,  LOGGER)  @  u  A  ^Owner(z,  tpm)  @  u  A  ^Owner(z,  y)  @  zz 
A  Mem(?,  to)  on  [zz",  zz]  A  (v  >  zz)  A  (zz"  <  zz  <  zzg)  A  I  G  L  A  ^Reset()  on  [zz",  zz]  A 
{tpm.key  ^  S)  D  ^Read(z,  /,  to)  @  zz  V  ^Contains(TO,  key{n),S)  @  v 
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Here  we  ask  the  reader  to  recall  about  our  splitting  the  startup  to  shutdown  time  into  intervals:  one  from 
startup  to  when  the  logger  incremented  the  counter,  and  the  other  interval  from  when  the  logger  incremented 
the  counter  to  shutdown,  as  stated  in  the  main  body.  We  do  so  using  the  following  predicate 

Early(M)  =  Vu'.Vj.  ^(LastReset(u')  @  u)  V  ^HT(j,  L,  LOGGER)  @  u  V  ^Counterup(j)  on  {u',u] 

where  LastReset(M')  @  u  =  {u'  <  u)  A  Reset()  @  u'  A  ^Reset()  on  {u',u].  Thus,  we  also  have 

^Early(M)  =  Bu'3j.  LastReset(M')  @  u  A  HT(j,  L,  LOGGER)  A  ^(^Counterup(j)  on  (u',?/]) 

We  can  split  formula  ^  into  two  parts  E  and  given  respectively  by 

7  h  yu,u"  S,v,l.  Early(M)  A  ^HT(i,  L,  LOGGER)  @  u  A  ^Owner{i,tpm)  @u  A  ^Owner(t,lA)  @  u 

A  Mem(l,  m)  on  [u",  m]  A  (v  >  u)  A  {u"  <  u  <  uq)  A  I  G  L  A  ^Reset()  on  [u”,  m]  A 
{tpm.key  ^  S)  D  ^Read(z,  l,m)  @  uV  ^Contains(TO,  key{n),S)  @  v 

7  h  Vu,  u” ,  i,  n,  TO,  S,  V,  1.  ^Early(u)  A  ^HT {i,  L,  LOGGER)  @  u  A  ^Owner(z,  tpm)  @  u  A  ^Owner(t,  V)  @  u 
A  Mem(l,  to)  on  [u",  u]  A  (v  >  u)  A  {u"  <  u  <  ug)  A  I  €  L  A  ^Reset()  on  [u",  u]  A 
{tpm.key  ^  S)  D  ^Read(i,  l,m)  @  uV  ^Contains(TO,  key{n),S)  @  v 

We  do  the  proof  in  three  parts:  first  for  the  location  M.disk.sealedkey  and  then  for  M.ram.keyloc  and 
M.  tpm  .V  .channel . 

Subsubcase  1:  I  =  m.disk.sealedkey 
Remember,  we  had  assumed  that 

^NR  =  Vu,  i,  TO.  Early(u)  A  {u  <  Ua)  A  ^HT  (i,  L,  LOGGER)  @  uD  ^Read(i,  M.disk.sealedkey,  m)  @  u 
which  takes  care  of  the  E  part  of  the  formula. 

For  the  -^E  part  we  again  split  time  into  two  parts:  one  part  till  the  time  the  logger  writes  the  sealed 
object  to  disk,  and  other  part  from  the  time  the  logger  writes  the  sealed  object  to  actual  shutdown. 

We  first  show  that  ^Contains(TO,  key{n),  S)  @  v  till  the  time  the  logger  writes  the  sealed  object  again  at 
shutdown.  Assume  the  antecedent  holds.  Look  at  the  following  parts  of  the  antecedent  of  the  required  to 
prove  formula  (with  universals  instantiated):  ^Early(M)  A  Mem{M .disk.sealedkey,  m)  on  [u" ,u]  A  {v  >  u)  A 
{tpm.key  ^  S).  First,  note  that  by  definition  of  of  ^Early(M)  choosing  fresh  values  u',j  we  get 

LastReset(M')  @u  A  HT(j,  L,  LOGGER)  @u  A  3uc.{u'  <  Uc  <  u)  A  Counterup(j)  @  Uc 

The  partial  correctness  for  the  unseal_data  function  [unseal_data](y,  ut,  Ue,j,  x)  implies  3to,  d,  (uh  < 
Uu  <  Ue)  A  Unseal(fc,  TO,  d,  tpTO.fcey)  @  Uu  A  Owner{k,  tpm)  @  t6„.  Thus,  we  have  using  the  order  of  execution 
of  programs  that  (note  Uc  is  the  time  when  counter  was  incremented) 

3c,m' ,Uu,Ud,Uyj,Us.  {u'  <  Us  <  Uyj  <  Ur  <  Ud  <  Uu  <  Uc)  A  Counterval(c)  @  Uu  A  Unseal(fc,  to',  d)  @ 

A  0\i\/ner{k,tpm)  @  Uu  A  Mem{M.disk.sealedkey,  m')  @  Ud  A  ReaclLock{J,  M.disk.sealedkey)  @  Ur  A 

WriteLock(j,  M.dis/c.sea/edfcey)  @  Uw  A  Start(j)  @  Us 

Pick  fresh  variables  for  existential,  and  we  use  the  same  names  as  the  quantifier  variables.  We  use  the 
following  short  form  notation  for  sake  of  readability 

Unseal^  j—(fc,  to',  d)  @  =  Counterval(c)  @  A  Unseal(fc,  to',  d)  @  Uu  A  Owner(fc,tpTO)  @ 

The  following  is  immediate  (for  given  Uu,Uc)  from  the  monotonicity  of  the  counter: 

Vj, u,c,c*  .  {uu  <  Uc  <  u)  A  Counterup(j)  @  Uc  A  Counterval(c)  @  D  Counterval(c*)  @  u  A  {c*  >  c) 
Also,  we  have 

Vj,M.  Start(j)  @  Us  A  {us  <  u)  A  ^Reset()  on  (us,u]  A  HT(j,  L,  LOGGER)  @uD  HT(j,  i,  LOGGER)  on  [us,u] 
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Next,  note  that  under  assumption  about  root  threads  NoAdv  and  Ax7wr  we  have  {ip  denotes  all  the  existential 
that  have  been  picked) 

'Y,ip\-  Vu'.  {u'  <  Us  <  <  Ur  <  u)  A  ^Reset()  on  {u' ,  u]  A 

HT(j,  L,  logger)  on  [us,u]  A  Re3idi.ock{j,  M.disk.sealedkey)  @  Uw  A  Wr\teLock(j,  M. disk. sealedkey)  @  Uw 
A  -^\Nnte{j,  M.disk. sealedkey,  v')  on  {uw,u]  D  \/i.—N\lr\Xe{i,  M.disk. sealedkey ,v')  on  {uyj,u] 

Thus,  by  preservation  of  memory  value,  given  no  writes,  (for  all  values  m') 

7,  ■(/>  h  \/v' ,m' .  {u'  <  Us  <  Uw  <  Ur  <  Ud  <  u)  A  ^Reset()  on  [u' ,u]  A  WriteLock(j,  M.disfc.sea^edfce?/)  @  Uw 
A  R&zdLock{j ,  M .disk. sealedkey)  @  Ur  A  HT(j,  L,  LOGGER)  on  [■Us,^]  A  Mem{M. disk. sealedkey,  m')  @  Ud  A 
-\Nr\Xe{j,M. disk. sealedkey,  v')  on  {uuj,u\  A)  Mem{M .disk. sealedkey ,  m')  on  [ud,u] 

But,  we  know  from  assumed  true  antecedent  of  that  Mem{M. disk. sealedkey,  m)  on  [u" ,  u],  which  implies 
m'  =  m.  Also,  by  definition  of  Contains  for  all  S 

Mem{M. disk. sealedkey,  m)  @u  A  Unseal^  m,  d)  @  A  Counterval(c*)  @  u  A  {c*  >  c)  A  {tpm.key  ^  S) 

{uu  <  u)  A  {v  >  u)  D  ^Contains(TO,  key{n),S)  @  v 

Thus,  we  have  (using  relaxation  of  the  consequent  with  Read) 

7,  h  yi,v',m.  {u'  <  Us  <  Uyj  <  Ur  <  Ud  <  u  <  v)  A  ^Reset()  on  {u' ,u]  A  \NnXeLock{j,  M. disk. sealedkey)  @  u^ 

A  ReadLock{j,  M.disk. sealedkey)  @  Ur  A  HT(j,L,  LOGGER)  on  [us,u]  A  Mem{M. disk. sealedkey,  m)  @  Ud  A  {tpm.key  ^  S) 
A  Unseal^  (A:,  m,  d)  @  A  -^\NnXe{j,  M.disk. sealedkey ,v')  on  {uw,u]  D 

^Contains(TO,  key{n),S)  @  v  V  ^Read(i,  {M.disk. sealedkey,  m)  @  u  {BeforeFinalSeal) 

This  part  takes  care  of  the  time  till  logger  writes  the  sealed  key  at  shutdown. 

To  reason  about  the  shutdown  phase  (after  the  logger  writes  the  sealed  key)  we  proceed  below.  We  know 
from  the  logger  and  shutdown  expression  that 

Vuz.  {uz  <U)  A  HT(j,  L,  logger)  @  Uz  A  V\lnXe{j,  M.disk. sealedkey,  v)  @  Uz  A 
^Reset()  on  [uz,u]  D  Mem (M.ram.s/i, —1)  on  [uz,u] 


Thus,  we  have 

7,  h  yuz,v' .  {u'  <  Us  <  Uw  <  Ur  <  Uz  <  u)  A  ^Reset()  on  {u' ,u\  A  WriteLock(j,  M.disA:.sea/edA;ey)  @  Uw 
A  ReadV.ock{j ,  M .disk. sealedkey)  @  Ur  A  HT(j,  L,  LOGGER)  on  [■Us,'u]  A  V\/nXe{j,  M .disk. sealedkey ,  v')  @  Uz 
D  Mem(M.raTO.sd,  — 1)  on  [uz,u] 

Next,  note  that  under  assumption  NoAdv  about  root  threads  we  have 

Mem{M.ram.sh,  —1)  @u  A  Owner(i,  root)  @  u  A>  ^Read(A,  M. disk. sealedkey ,  m)  @  u  . 

Thus,  using  Ax7rd  we  get  for  all  i,  {ur  <  Uz  <u)  A  ReadLock(j,  M .disk. sealedkey)  @  Ur  A  HT(j,  L,  LOGGER)  on 
[us,u]  A  Mem{M.ram.sh,  —1)  @  uD  ^Read{i,  M.disk. sealedkey  ,v)  @  u.  Thus,  we  have 

'Y,ip\-  yi,Uz,v' ,m.  {u'  <  Us  <  Uw  <  Ur  <  Uz  <  u)  A  ^Reset()  on  {u' ,u]  A  y^nXe\-Ock{j,  m.disk. sealedkey)  @  u^ 

A  ReadLock{j,  M.disk. sealedkey)  @  Ur  A  HT(j,  L,  LOGGER)  on  [■Us,'u]  A  y\/nXe{j,  M .disk. sealedkey ,  v')  @  Uz 
D  -^Read{i,  M.disk. sealedkey,  m)  @  u 

Thus,  moving  the  Vuz  as  an  existential  into  the  precedent  we  get  3uz.  {u^j  <  Uz  <  u)  A  Write(j,  M.disk. sealedkey,  v')  @ 

Uz  which  is  same  as  ^{-^\Nr\Xe{j,  M.disk. sealedkey,  v)  on  (m^jjw]).  Then,  the  strengthening  antecedent  and 
relaxing  the  consequent  we  get 

7,  ■(/>  h  yi,v' ,m.{u'  <  Us  <  Uru  <  Ur  <  Ud  <  u  <  v)  A  ^Reset()  on  {u' ,u]  A  \NnXeLock{j,  M.disk. sealedkey)  @  Uw 
A  ReadLock{j,  M.disk. sealedkey)  @  Ur  A  HT(j,  L,  LOGGER)  on  [ms,u]  A  Mem{M. disk. sealedkey,  m)  @  Ud  A  {tpm.key  ^  S)  A 
{^{-i\NnXe{j,  M.disk. sealedkey ,v')  on  {uw,u])  A  {v  >  u)  D 
^Contains(TO,  key{n),S)  @  v  y  ^Read(i,  M.disk. sealedkey,  m)  @  u 
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Combining  this  with  the  formula  (Before  Final  Seal)  we  get  (note  same  consequent) 

7,  h  yi,v' ,m.{u'  <  Us  <  Uw  <  Ur  <  Ud  <  u  <  v)  A  ^Reset()  on  (u' ,u]  A  \NnteLock{j,  M.disk.sealedkey)  @  Uw 
A  Readl.ock{j,  M.disk.sealedkey)  @  Ur  A  HT(j,  L,  LOGGER)  on  [ngju]  A  Mem{M.disk.sealedkey,m)  @  Ud 
A  {tpm.key  ^  S)  A  {v  >  u)  D  ^Contains(m,  key{n),S)  @  v  V  ^Read(t,  M.disk.sealedkey,  m)  @  u 

Note  that  the  consequent  does  not  depend  on  any  of  the  existential  witnesses.  Thus,  we  have 

7  h  Vm,  u” ,  i,  S,  V,  m.  ^Early(u)  A  Mem{M.disk.sealedkey,  m)  on  [u" ,  m]  A  (u  >  u) 

A  {tpm.key  ^  S)  A)  -^Conta\ns{m,  key{n),  S)  @  u  V  -^Rea(i{i,  {M.disk.sealedkey ,m)  @  u 

The  antecedent  can  be  strengthened  to  obtain  the  desired  result  -^E. 

Next,  we  show  the  proof  for  that  for  I  =  M.ram.keyloc.  As  the  proof  for  M.tpm.v. channel  is  similar  we 
skip  that  part.  The  proof  is  similar  to  the  last  part  where  we  split  the  required  to  prove  formula  into  two  E 
and  one  with  Early  and  one  with  ^Early. 

Subsubcase  2;  I  =  M.ram.keyloc 

We  start  with  proving  E.  Assume  part  of  antecedent  of  E  after  instantiating  all  universals:  Early(u)  A  {v  > 
u)  A  tpm.key  ^  S.  Then,  Early(u)  holds.  Choose  u'  such  that  LastReset(M')  @  u  (there  always  exists  such  a 
u').  Thus,  this  implies  that  HT(j,  L,  LOGGER)  @  u  D  ^Counterup(j)  on  {u' ,u].  First,  the  following  hold  due 
to  the  operational  semantics  of  reset,  Reset()  @  u'  A)  Mem{M. ram. keyloc,  null)  @  u'.  Again,  using  Axl  we 
get 

ym,u".  Mem{M.ram.keyloc,m)  @  u”  A  {u"  <  u)  A  ^Reset()  on  {u',u] 

A>  {m  =  null)  V  3k,  u'".  {u'  <  u!"  <  u")  A  \Nnte{k,  M .ram. keyloc,  m)  @  u'" 

We  know  that  since  Early(M)  holds  we  have 

^Reset()  on  {u'  ,u]  A  HT(j,  L,  LOGGER)  @uD  ^Reset()  on  {u'  ,u]  A  HT(j,  L,  LOGGER)  @u  A  ^Counterup(j)  on  {u'  ,u] 
Also,  we  know  from  analysis  of  logger  program  that 

yj,v' .  ^Reset()  on  {u' ,u\  A  HT(j,  L,  LOGGER)  @  u  A  ^Counterup(j)  on  {u',u]  A>  -^y\/nte{j ,  M .ram. keyloc,  v')  on  {u',u] 

Thus,  by  using  modus  ponens  on  the  last  two  formulas  we  get 

yj,v' .  ^Reset()  on  {u',u]  A  HT(j,  A,  LOGGER)  @  uD  -^\Nnte{j,  M.ram.keyloc, v')  on  {u'  ,u] 

Also,  from  the  tpm  program  we  know  that 

Vi,  u'.^Reset()  on  {u',u]  A  Owner(i,tpm)  @  u  D  -^\Nr\te{i,  M.ram.keyloc,  v')  on  {u',u] 

Also,  from  the  verifier  program  we  know  that 

Vi,  u'.^Reset()  on  {u' ,  u]  A  Owner(i,  V)  @  uA)  ^Write(i,  M.ram.keyloc,  v')  on  {u' ,  u] 

Thus,  combining  last  three  formulas  we  have 

Vi,  u'.^Reset()  on  {u' ,  u]  A  (Owner(i,  C)  @  u  V  Owner(i,  tpm)  @  m  V  HT(j,  L,  LOGGER)  @  u) 

D  -^\Nnte{i,  M.ram.keyloc,  v')  on  {u',u\ 

which  can  be  rearranged  as 

Vi,  v' ,  M^.^ResetO  on  {u' ,  u]  A  Write(i,  M.ram.keyloc,  v')  @  Uw  A> 

^Owner(i,  C)  @u  A  ^Owner(i,  ipm)  @u  A  ^HT(i,  A,  LOGGER)  @  u  {Wl) 

As  shown  above,  we  also  have 

(to  =  null)  V  3k,u".  {u  <  u"  <  u")  A  \Nr\te{k,  M.ram.keyloc, m)  @  u"' 
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Clearly 


m  =  null  A  {v  >  u)  Z)  ^Contains(m,  key{n),  S)  @  v 

In  the  other  scenario  (m  7^  null),  using  the  above  result  W1  and  thread  k  writing  to  memory  loca¬ 
tion  M.ram.keyloc  we  get  ^Owner(fc,y)  @  u'”  A  ^Owner(fc,  tpm)  @  u'”  A  ^HT(fc,  L,  LOGGER)  @  u'”  A 
\Nnte{k,  M.ram.keyloc,ni)  @  u'" . 

We  can  now  use  Ax2  and  HI  to  claim  Has(fc,m)  @  u'"  from  \Nr\te{k,  M.ram.keyloc,  m)  @  u'” .  As 
u'”  <  u  <  Uq  we  can  invoke  key0wnerln(t6"') 


keyOwnerln(u"')  =  Vm',  m,  n,  i,  S.  {u'  >  u'")  A  Has(i,  m)  @  u'"  A  Contains(m,  key{n),S)  @  u' 

A  -^{tpm.key  G  S)  Z>  HT(i,  L,  LOGGER)  @  u'"  V  Owner{i,tpm)  @  u'"  V  Owner(i,C)  @  u'" 

to  claim  that  (using  v  >  u  >  u'") 

^HT(A:,  L,  LOGGER)  @  u'"  A  ^Owner{k,tpm)  @  u'"  A  ^Owner(A:,  C)  @  u"  A  (v  >  u'") 

A  Has(fc,m)  @  u'”  A  -^{tpm.key  G  S)  D  ^Contains{m,  key{n),  S)  @  v 

Thus,  we  infer  ^Contains(m,  fcey(n),  S')  @  v  which  can  be  weakened  to  ^Contains)™,  fce?/(n),  S)  @  u  V 
^Read(i,  M.ram.keyloc,  m)  @  u  for  any  i,  and  is  independent  of  all  existentially  chosen  fresh  variables.  Thus, 
we  infer 

7  h  Vu,  V,  S,  i,  n,  m.  Early(t6)  A  (v  >  u)  A  tpm.key  ^  S  D 

^Contains(m,  key{n),  S)  @  v  y  ^Read(i,  M.ram.keyloc,  m)  @  u 

which  can  be  strengthened  to  obtain  E. 

We  skip  the  proof  of  -^E  here,  but,  state  that  the  proof  relies  on  the  fact  that  the  logger  has  write  lock 
on  M.ram.keyloc  and  only  the  logger  ever  reads  that  location. 

E.2  Proving  property  3  and  4 

Next,  we  prove  property  3  and  4,  i.e.,  Vu.m  >  Ua  Z)  oldKeyAdv(u,  Wa)  A  oldKeyNotlnMem('u, Uo). 

We  do  transfinite  induction  on  u.  We  first  prove  the  base  case  where  u  =  Ua-  oldKeyAdv(Ma,  Wa)  holds  as 
the  antecedent  is  false  because  of  keyOwnerln(M).  We  prove  oldKeyNotlnMem(t6a,  Uo)  next. 

By  analyzing  the  program  of  logger  we  have 

yi,ui,k,k' ,ke,  S,m.  (fc  >  1)  A  LastLogldx(fc,  u;,  Wa)  A  HT(i,  T,  LOGGER)  @  Ua  A 

inMem(f,  key{ke))  @  Ua  A  [1  <  k'  <  k)  A  inMem(f,  m)  @  Ua  Z)  ke>  k  +  \  A  ^Contains(m,  key{k'),S)  @  Ua 

From  program  analysis  of  tpm  we  have 

yi,ui,k,k',ke,S,m.  {k  >  1)  A  LastLogldx(fc,  u;,  Wa)  A  Owner(z,tpm)  @  Ua 

inMem(z,  key{ke))  @  Ua  A  [1  <  k'  <  k)  A  inMem(z,  m)  @  Ua  Z>  kf.'>  k  +  1  A  ^Contains(m,  key{k'),S)  @  Ua 

Combined  with  the  already  proven  keyOwnerln(Ma)  we  get  that 

yi,ui,k,k',S,m.  {k  >  1)  A  LastLogldx(fc, m;,  Wa)  A  {1  <  k'  <  k)  A  ^Owner{i,V) 

A  inMem(z,  m)  @  Ua  A  tpm.key  ^  S  Z)  ^Contains(m,  key{k'),S)  @  Ua 

The  above  can  be  simplified  by  noting  that  yi.3i.  CanRead(z,l)  and  verifier  cannot  read  memory  in  machine 
M  to  get 

yi,  ui,k,  k' ,  S,  m.  (fc  >  1)  A  LastLogldx(fc,  ui,Ua)  A  {1  <  k'  <  k) 

A  [I  G  M)  A  Mem(?,  m)  @  Ua  D  ^Contains(m,  key{k'),S)  @  Ua 

which  proves  oldKeyNotlnMem(uo, rta)- 

For  the  induction  hypothesis,  assume  that  oldKeyNotlnMem(M,  Ua)  A  oldkeyAdv(M,  Wa)  for  all  Ua  <  u  <  uq 
for  some  uq.  We  need  to  show  oldKeyNotlnMem(Mo,  Uo)  A  oldkeyAdv(Mo,  Ma)- 
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oldKeyNotlnMem(Mo?  Ma)  holds:  We  do  so  by  contradiction. 

Assume  the  formula  oIdKeyNotInMem  does  not  hold  for  ug,  then  we  obtain  a  contradiction.  The  negation  of 
oldKeyNotlnMem(uo, Ua)  is 

Bio,  ui,  k,  k' ,  So,  m.  (ug  >  Ua)  A  (/c  >  1)  A  P{k,  ui,Ua)  A  {1  <  k'  <  k)  A  Mem(/o,  m)  @  uq  A 
tpm.key  ^  S  A  Conta\ns{m,  key {k') ,  Sg)  @  ug 

Choose  fresh  values  for  existential  and  let  the  above  formula  be  ijj.  From  the  induction  hypothesis  we  know 
oldKeyNotlnMem(uo, Ma)  is  true,  thus, 

Mem(lo,m)  @  ug  A  Mem(?o,  m')  @  Ua  D  m  ^  m' 


Thus, 


Bjo,u,^.  {ua  <  Uu,  <  Uo)  A  \Nr\t&{jg,lg,m)  @ 


Thus,  from  Ax2  and  HI  we  get 

Bj,Uu,.  {ua  <Uw  <  Ug)  A  \Nr\te{jg,lg,m)  @Uw  A  Has(jo,m)  @ 

Now,  from  oldkeyAdv(Mu,,  rta)  combined  with  ip  and  Has(jo,m)  @  it  is  possible  to  say  that 

HT( jo,  T,  LOGGER)  @Uu,\/  Owner{jg,  tpm)  @  V  Owner(jo,C)  @  u^,  (jgthreads) 


It  is  possible  to  prove  by  analyzing  programs  that 

7,  h  Vfc',  k,  I,  m,  u,  ui,i,  v,  S.  {ua  <  u  <  Ug)  A  {u  <  v)  A  HT {i,  L,  LOGGER)  @  u  A  P{k,  ui,Ua)  A 

{\  <k'  <k)  A  Write(f,  l,m)  @  u  A  Contains(TO,  key{k'),  S)  @  v  A  -^{tpm.key  G  S)  D  k'  >  k  +  1 
7,  h  Vfc',  fc,  I,  m,  u,  i,  v,  S.  {ua  <  u  <  ug)  A  {u  <  v)  A  Owner(z,  tpm)  @  u  A 

P{k,  ui,Ua)  A  (1  <  fc'  <  fc)  A  Write(i,  l,m)  @  u  A  Contains(m,  key{k'),S)  @  v  A  -^{tpm.key  €  S')  D  fc'  >  fc  +  1 
7,  •(/>  h  Vfc',  fc,  I,  m,  u,  i,  V,  S.  {ua  <  u  <  ug)  A  (u  <  v)  A  Owner(z,  C)  @  u  A  P(k,  ui,Ua)  A 

(1  <  fc'  <  fc)  A  Write(r,  l,m)  @  u  A  Contains(TO,  key{k'),  S)  @  v  A  -^{tpm.key  €  S)  D  fc'  >  fc  +  1 

The  above  proof  relies  on  the  induction  hypothesis  oIdKeyAdv  and  oIdKeyNotInMem  to  ensure  that  the 
log  entries  do  not  contain  keys  with  index  lower  than  fc  +  1.  Then,  instantiating  i  with  jo,  I  with  Ig,  m  with 

TO,  V  with  Mo  and  S  with  Sg,  and  combined  with  ip  and  (jgthreads)  we  conclude  that  fc'  >  fc  +  1,  but,  we 

also  have  from  ip  that  k'  <  k  which  is  contradiction. 


Proving  oldKeyAdv(Mo, 'U'a)  holds:  We  do  so  by  contradiction. 

Assume  the  formula  oldKeyAdv(Mo,  Ma)  does  not  hold,  then  we  show  a  contradiction. 

3io,  TO,  V,  Sg,  ka,  Ug,  U[.  {v  >  Ug  >  Ua)  A  Has(ro,  to)  @  Mo  A  Contains(TO,  key{ka),  Sg)  @  v  A  ^HT(io,  L,  LOGGER)  @  ug 
A  ^Owner(ro,  tpm)  @  ug  A  ^Owner(io,  V)  @  ug  A  P{k,  ui)  A  tpm.key  ^  Sg  A  {ka  >  1)  A  (fca  <  fc  +  1) 

Denote  above  by  ip.  Pick  the  existential  values  (denote  them  by  the  same  variable  names).  From  Has 
we  infer  that  in  past  at  time  Ur,  ig  read  (or  hmaced)  a  message  to'  from  a  location  I  that  contained  to 
and  ^Reset()  €  [m^jMo].  The  receive  is  ruled  out,  as  by  induction  hypothesis  non-logger  ,  non-verifier  and 
non-tpm  threads  do  not  have  fcey(fco)  as  fca  <  fc  +  1,  and  the  logger,  verifier  and  tpm  do  not  send  out  the 
key.  We  reason  about  the  read  case  below,  deriving  a  contradiction.  (The  hmac  case  is  similar  so  we  skip  it). 

Since  the  message  read  to'  contained  to  we  know  there  exists  a  S'  such  that  Contains(TO',  to.  S').  Also,  by 
the  security  of  the  tpm  key  we  have  tpm.key  ^  S' .  As  argued  in  previous  part  we  have  Contains(TO',  key{ka),  5"U 
Sg)  @  V.  The  ^Reset()  G  [Mr,Mo]  with  the  assumed  assertion  that  ig  is  not  the  logger,  tpm  or  veriher  at  time 
Ug  implies 

^HT(io,  A,  LOGGER)  @  u^  A  ^0\Nner{ig,tpm)  @  Ur  A  ^Owner(zo,  P)  @  Ur 

Consider  two  cases  Ur  <  Ua  and  Ur  >  Ua.  We  first  derive  a  contradiction  from  the  hrst  case.  From 
keyOwnerln(Mr)  we  know  that 

yv' ,S,i' .  {ur  <  Ua)  A  Has(V,TO')  @  Ur  A  {tpm.key  ^  S)  A  ^HT(z',  L,  LOGGER)  @  Ur  A  ^Owner(i',  tpm)  @  Ur 
A  ^Owner(z',  V)  @  Ur  A  {v  >  Ur)  D  ^Contains(TO',  key{ka),  S)  @  v' 
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Instantiate  v'  with  v  and  S  with  S'  U  Sq  and  i'  with  iq.  Thus,  the  precedent  is  true  (using  'iji)  and  we  get 
^Contains(m',  key{ka) ,  S' U  Sq)  @  v,  but,  we  already  concluded  that  Contains(m',  key{ka) ,  S' U  Sq)  @  v.  Thus, 
we  have  a  contradiction. 

Next,  consider  the  case  when  read  time  Ur  >  Ua-  Let  the  location  read  be  1.  Thus,  Has(io,  m)  @  Ur-  Then, 
as  before  there  is  a  set  S'  such  hat 

tpm.key  ^  S'  U  Sq  /\  Mem(?,  m)  @  Ur  A  Contains(m,  key{ka),  S'  U  So)  @  uq 

However,  this  violates  the  induction  hypothesis  oldKeyNotlnMem('Ur)  Wa)  for  Ur  <  uq.  Thus,  Ur  must  be  uq. 
Thus,  Mem(?,m)  @  Uq  A  Conta\ns{m,  key (ka),  Sq)  @  uq-  From  the  induction  hypothesis  oldKeyAdv('u)  we 
know  that  Contains(m,  A:ey(fca),  S'o)  @  uq  D  ^Mem(^,  m)  @  u  where  u  <  uq.  Thus,  we  get 

(u  <  Uq)  a  Mem(/,TO)  @  uq  A  ^Mem(^,m)  @  u 


Using  Axl  we  get 

3jo,  u' .  {u  <  u'  <  Uq)  a  Write(jo,  I,  w)  @  u' 

Using  Ax2  we  get  (with  the  jo  above) 

3u",u'.  {u  <  u"  <  u'  <  Uq)  a  Has(jo,TO)  @  u"  A  Write(jo, to)  @  u'  A  ^Reset()  on  [u",u'] 

Now,  as  in  the  last  part,  from  oldKeyAdv)^",  Ua)  combined  with  and  Has(jo,TO)  @  u"  it  is  possible  to  say 

that 

HT (jo,  L,  LOGGER)  @  u"  V  Owner(jo,  tpm)  @  u"  V  Owner(jo,  V)  @  u" 

Using  the  above  assertion  that  A  ^Reset()  on  [u" ,u']  we  get 

HT(jo,  iv,  LOGGER)  @u'  y  Owner(jo,  tpm)  @  u  V  Owner(jo,  V)  @  u 

Now,  just  as  in  the  last  part  (by  analyzing  programs)  we  can  show  that  ka  >  k  +  1,  but,  we  already  assert 

that  ka  <  k  +  1,  which  is  a  contradiction. 

E.3  Main  Result 

Finally,  we  prove  the  main  result  of  the  paper 

7  hVfc,  k' ,  Ub,  Ue,  ui,Ur,  Uyj,  i,j,  log,  n,Jhm.  HT(z,  V ,  VERIFIER)  on  [ub,  Me]  A 
[ub  <  Uc  <  Ur  <  Uv  <  Me)  A  Send(z,  VERIFY)@Ub  A  New(z,  nonce)@Uc  A 
Recv(z,  {log[n],n,fhm))  @  Ur  A  VerifyHmac(z,  j?z7?z,  nonce,  key{n  +  1))@m„  A 
((Mr  <  Ua)  A  LaStLogldx(fc,  Mi,  Mr))  A  ((Mr  >  Ua)  A  LaStLogldx(fc,  M/ ,  Ma))  A 
(1  <  k'  <  k)  A  {ui  >  Uw)  A  V\/nte{j,jileloc{k'),v)  @  Uw 
A  HT(j,  L,  logger)  @  Uw  a  data{v)  =  data{log{k')) 

where 

LaStLogldx(fc,M,Me„d)  =  (fc  >  0)  A  (m  <  Uend)  A 

yu' ,i,j.  HT(z,  L,  logger)  @  u  a  {u  <  u'  <  Uend)  A  (k  >  1)  A  \Nnte{i,  fileLoc{k) ,  v)  @  u  A 
HT(j,L,  LOGGER)  @  u'  A  -^\N nte{ j,  fileLoc(k  +  1),m)  @  u' 

We  assume  that  the  required  to  prove  formula  does  not  hold  and  derive  a  contradiction.  The  negation  is 

7  \-3k,  k',  Ub,  Ue,  ui,Ur,  Uyj,  i,j,  log,  n,Jhm.  HT(z,  V ,  VERIFIER)  on  [Mf,,  Me]  A 
[ub  <  Uc  <  Ur  <  Uy  <  Ue)  A  Send(z,  VERIFY)@Ub  A  New(z,  nonce)@Uc  A 
Recv(z,  {log[n],n,fhm))  @  Ur  A  VerifyHmac(z,  j?i77z,  nonce,  key{n  +  l))@Mr  A 
((Mr  <  Ua)  A  LaStLogldx(fc,  Mi,  Mr))  A  ((Mr  >  Ua)  A  LaStLogldx(fc,  Mi ,  M^))  A 
(1  <  k'  <  k)  A  {ui  >  Uw)  A  V\/nte{j,jileloc{k'),v)  @  Uy, 

A  HT(j,  L,  logger)  @  Uyy  a  {data{v)  ^  data{log{k'))) 
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Denote  the  above  as  ^|)  after  picking  fresh  values  for  the  existential  with  same  variable  names,  except  jo 
for  the  variable  j.  By  the  definition  of  LastLogIdx  and  ip  we  get  that  ui  <  min(wr,t6a)- 
Also,  by  analyzing  the  program  of  the  verifier  we  know  that 

HT(*,  D,  verifier)  on  [ub,Ue\  A  VerifyHmac(i,  JTim,  nonce,  key{n  +  A@  u  D 

3u.  {ur  <  u  <  Uv)  A  \/er\fyHmac{i,data{k')mac,data{k')data,key{k'))  @  u 

Using  the  hmac  axioms  Ax9  and  AxlO  for  VerifyHmac(f,  data{k')mac^  data{k')data,  key{k'))  and  the  fact  that 
data  was  received  at  time  Ur  we  get 

VerifyHmac(*,  fhm,  nonce,  key{n  +  1))  @  D  3j,  I,  u' .{u'  <  Ur)  A  Hmac(j,  data{k')data,  I,  data{k')mac)  @  u' 

A  inMem(j,  fce2/(fc'))  @  u' 

Let  the  above  witness  for  j  be  f .  First,  we  show  that  u'  <  Ua-  Assume  the  contrary  u'  >  Ua,  which  also  im¬ 
plies  that  Ur  >  Ua-  Hence,  LastLogldx(fc,  ui,Ua)  holds,  and  inMem(j,  key{k'))  @  u'  implies  31.  Mem(Z,  key{k'))  @ 
u' .  We  show  using  oldKeyNotlnMem(t6', rta)  a  contradiction. 

From  oldKeyNotlnMem(u',  Uo)  we  can  claim  that  k'  >  k.  To  get  this,  re-arrange  oIdKeyNotInMem  to  move 
the  ^Contains  to  antecedent  as  ^Contains  and  the  k'  <  k  to  consequent  as  k'  >  k. 

oldKeyNotlnMem(u,  Ua)  =  VI,  ui,k,  k' ,  S,  m.  {u  >  Ua)  A  (fc  >  1)  A  LastLogldx(A:,  ui,  Ua)  A 

A  (1  <  k')  A  Mem(l,  m)  @  u  A  tpm.key  ^  S  A  Contains(m,  key{k'),  S)  @  u 
D  (fc'  >  k) 

We  already  showed  that  LastLogldx(A:,  up  Ua)  and  Mem(l,  fcey(fc'))  @  u',  and  take  S  =  (p.  Hence,  we  can 
infer  that  k'  >  k.  However,  we  asserted  above  that  k'  <  k  which  is  a  contradiction.  Thus,  u'  <  Ua- 
It  is  possible  to  show  that 

Vj.  t^mac{j,data{k')data,l,data{k')mac)  @  u'  D  ^Owner{j,tpm)  @  u'  A  ^Owner(j,  U)  @  u' 

by  analyzing  the  tpm  and  verifier  program.  It  is  also  possible  to  show  using  keyOwnerln(u')  that 

inMem(j',  A:ey(fc'))  @  u'  A  {u'  <  Ua)  A  HT(j',  A,  LOGGER)  @  u'  V  Owner(/,  tpm)  @  u'  V  Owner(j',U)  @  u' 

Thus,  we  obtain  HT(j',  A,  LOGGER)  @  u' .  Also,  from  the  logger  program  it  can  be  shown  that 

yj,u'.  HT(j,  A,  LOGGER)  @  u'  A  Hmac{j,data{k')data,lidata{k')mac)  @  w' 

A  P{k,ui,Ua)  A  {1  <k'  <k)  A  {u'  <  Ua) 

A  3u'^.  \Nnte{j,  fileloc{k'),data{k'))  @  u'^,  A  {u'  <  u'^^  <  ui)  A  ^Reset()  on  [u' ,u'J\  A 
yj",u,v'.  (u  <  Ua)  A  (u  yf  u'a,)  A  HT(j",  A,  LOGGER)  @uA  -^\Nnte{j" ,  fileloc{k'),v')  @  u 

Instantiate  j  =  j'  and  u'  =  u'  in  the  above  formula. 

The  antecedent  holds  by  our  assumptions  and  hence  does  the  conclusion.  We  already  have  HT (jo,  A,  LOGGER)  @ 
Uu,  and  Ura  <  Ua  and  \N r\te{ j o,  fil el oc{k'),v)  @  Uw,  which  means  that  a  possible  value  for  u'^  is  u^,.  Now, 
the  forall  in  the  consequent  implies  that  u(„  =  u^,  since  for  no  other  value  of  u  is  there  a  write  to  fileloc{k'). 
Also,  from  ^Reset()  on  [u' ,Uyj]  and  HT(j',  A,  LOGGER)  @  u'  we  get  that  HT(j',  A,  LOGGER)  @  u^,  but,  we 
already  have  HT  (jo.  A,  LOGGER)  @  Uw  (from  ip).  Thus,  j'  =  jo- 

Again  from  \Nr\te{j' ,  fileloc{k'),data{k'))  @  u'^,  we  get  \Nr\te{jo,  fileloc{k'),data{k'))  @  Uw,  which  com¬ 
bined  with  \Nr\te{jo,  fileloc{k'),v)  @  u^  means  v  =  data{k').  However,  we  also  have  v  yf  data{k')  (from  ip). 
Thus,  we  have  a  contradiction. 


F  Protocol  Encoding 
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Logger  program 
LOGGER  = 

call  logger_start(); 
call  logger _body(); 

logger  _start(j  = 

call  setup_loggerchaiinel(_seZ/); 
writelock  M .ram.keyloc; 
readlock  M .ram.keyloc, 
writelock  M .disk.sealedkey, 
readlock  M .disk.sealedkey, 

/ /handles  shutdown  attack 
s  —  read  M .disk.sealedkey, 
key  —  call  unseal_data(s); 
counterup  M .tpm.nv. counter. P,  / /counter  1 
write  M .ram.keyloe,  key, 
write  M .ram.logger-os, —1; 
logger  _body()  = 

shstatus  =  read  M .ram.sh,  //shutdown  status 
key  =  read  M .ram.keyloc, 
data  =  recv; 

if  {data  ==  LOGGING.DONE 
A  shstatus  ==  —1) 
then  call  logger_shutdown(); 
else 

if  {data  ==  VERIFY) 

then  call  verify_logger(); 
else 

hm  =  hmac  data,  key, 

key'  =  hash  key, 

write  M .ram.keyloc,  key' ■, 

y  =  read  M .disk.currentpos\  //current  pointer 

write  M .disk. y,  {data,  hm); 

write  M .disk.eurrentpos,  y  +  1; 

verify_logger()  = 

eurr=  read  M .disk.eurrentpos; 

start  —  read  M  .disk.startoffile; 

log  —  read  M .disk.startoffile;  / /reads  whole  file 

nonce  —  recv; 

hm  —  hmac  nonce,  key; 

send(Zosi,  curr  —  start,  hm);  / /file,  size,  hm 

logger_shutdown()  = 

s  —  read  M  .tpm.nv.  counter.  1; 
key  =  read  M .ram.keyloc; 
sk  =  call  seal_data(A:e2/,  1,  s  +  1); 
write  M .disk.sealedkey,  sk; 
write  M .ram.logger^sh, —1; 


unseal_data(s)  = 

write  M .tpm.v. channel,  UNSEAL-COMMAND; 

/ /notify  TPM  of  command 
write  M .ram.loggerApm, —2; 

/ /wait  for  response  of  TPM 
poll  M  .ram.logger_tpm, —1; 

/ /put  data  on  channel 
write  M .tpm.v. ehannel,  s; 

j /notify  TPM  of  data 
write  M .ram.loggerApm,  1; 

/ /wait  for  response  of  TPM 
poll  M .tpm.logger_tpm,2; 

/ /read  response  of  TPM 
X  =  read  M .tpm.v. channel; 
x; //return  x 

seal_data(dota,  counterindex,  counter)  = 

write  M .tpm.v. channel,  SEAL-COMMAND; 
write  M .ram.logger-tpm, —2; 

/ /wait  for  response  of  TPM 
poll  M .ram.loggerApm, —1; 

/ /put  data  on  channel 
write  M .tpm.v. channel, 

{data,  counterindex,  eounter); 

/ /notify  TPM  of  data 
write  M .ram.logger_tpm,  1; 

/ /wait  for  response  of  TPM 
poll  M .tpm.logger-tpm,2; 

/ /read  response  of  TPM 
a;  =  read  M .tpm.v. channel; 
x; 

OS  program 
OS  = 

call  init(); 
id  =  fork  LOGGER,  L; 
writelock  M .ram.logger-OS,id; 
write  M .ram.logger_os, —2; 
poll  M .ram.loggev-os, —1; 
writelock  M .ram.sh-os; 
write  M .ram.sh_os,  —2; 

id'  =  fork  SHUTDOWN,  root;  //enable  shutdown 
poll  M .ram.sh-os, —1; 
fork  PRODUCER; 

e'; 

SHUTDOWN  = 
writelock  M .ram.sh; 

//only  the  thread  that  locks  ram.sh  can  reset 
write  M .ram.sh_os, —1; 
write  M. ram.sh,—!; 

//write  -1  non-deterministically  at  any  time 
poll  M .ram.loggersh,  —1;  //wait  for  logger 
reset; 


30 


Verifier  program 

VERIFIER  = 
send  {VERIFY,0)- 
key  =  hash  SS\ 
nonce  =  new; 
send  nonce', 

{alldata,  size,  finalhm)  =  recv; 

call  verif  ier_loop(0,  key,  size,  nonce,  finalhm,  alldata)', 

verif  ier_loop(n,  key,  size,  nonce,  finalhm,  alldata)  = 
if  (n  ==  size) 

then  verifyhmac  finalhm,  nonce,  key, 
else 

{log,  hm)  =  alldatafin)', 
verifyhmac  hm,  log,  key, 
key’  =  hash  key, 

call  verif ier_loop(n  +  1,  key’,  size,  nonce,  finalhm) 


TPM 
TPM  = 

call  tpm_body(); 

tpm_body()  = 

//private  key  of  TPM 
prvkey  =  read  M .tpm.nv.locked.prvkey; 

/ /wait  for  command 
poll  M .ram.loggerRpm, —2; 
command  =  read  M .tpm.v. channel; 
write  M .ram.loggerRpm, —1; 
poll  M  .ram.loggerRpm,  1; 
if  {command  =—  SEAL_COMMAND)  then 

{data,  counterindex,  count)  =  read  M .tpm.v. channel; 
s  —  seal  data,  counterindex,  count,  prvkey; 
write  M .tpm.v. channel,  s; 
else  if  {command  ==  UNSEAL^COMMAND) 
s  —  read  M .tpm.v. channel; 
data  =  unseal  s,  prvkey; 
write  M .tpm.v. channel,  data; 

/ /notify  caller  that  done 
write  M .ram.logger_tpm,2; 
call  tpm_body(); 

setup_loggerchannel(ici)  = 

//take  various  locks  on  communication  channels 
writelock  M .tpm.v. channel, id; 
readlock  M .tpm.v. channel,  id; 
writelock  M .ram.logger_tpm,id; 
readlock  M .ram.loggerRpm,  id; 
writelock  M .ram.logger.sh,  id; 
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